1.
InterWiki Markup Language (IWML) Version 0.1 Draft
Status
This document has no status whatsoever and is not part of any formal working group, process,
or plan. IT COMES WITH NO WARRANTEE WHATSOEVER, and is currently Copyright 2004 Murray Altheim,
All Rights Reserved. Upon release of the first DTD both this specification, the DTD and related
materials will all be released under a Creative Commons license.
This document is an early draft intended to show the direction of the project.
Abstract
This is a rapid design prototype (a version 0.1) for an InterWikiMarkupLanguage, intended to
capture an interoperable subset of common wiki functionality. It is not meant to support
everything that any wiki syntax is capable of representing, it is for reliable interchange
between wiki systems.
1.1.
Design Rationale
For further rationale on elimination of some modules, see the XHTML Basic Recommendation.
The requirements for InterWiki are not identical to that for small devices, e.g., IWML is
by design not constrained by memory footprint or tiny screens. But as an interchange syntax,
it does need to form a minimal, interoperable subset of wiki functionality.
1.1.1.
Retained Abstract Modules
Below are listed the "Abstract" Modules from XHTML, with justification given for their removal
or continued inclusion. The numbers next to the title are the section numbers from [XHTMLMOD].
- 5.1. Attribute Collections
- justification: all included as necessary for normal functionality
- 5.2.1. Structure Module
- justification: necessary for basic functionality
- 5.2.2. Text Module
- justification: everything is supported everywhere. I doubt anyone actually uses <samp>
<dfn> or <kbd>, so they could be removed, but why? They're just like <span> with some
minor semantics, and can be styled via a stylesheet.
- 5.2.3. Hypertext Module
- justification: let's get rid of this one.
(just kidding)
- 5.2.4. List Module
- justification: all typically supported in wiki
- 5.4.1. Presentation Module
- justification: keep what makes sense for convenience to keep. <span class="bold">
or even <strong> makes no sense when <b> will do. All accessibility arguments are
void with <b> and <i> since those two are supported in all tools. The only real
question is for <big>, <small>, <sup> and <sub>. The latter two are the only reasonable
way to do formulae, but <big> and <small> are unnecessary and better served by a stylesheet.
We keep <sup> and <sub>, get rid of <big> and <small>.
- 5.4.2. Edit Module
- justification: <del> and <ins> not hard to support, and likely useful for
diff marking wiki pages, a fairly common activity on wiki
- 5.4.3. Bi-directional Text Module
- justification: retained for international text support. Sad but true. I don't think
those who need it would be happy to have it gone. Not all text is left-to-right...
- 5.5.1. Basic Forms Module
- justification: as with XHTML Basic. Necessary for wiki functionality.
- 5.7. Image Module
- justification: wikis use images.
- 5.15. Metainformation Module
- justification: necessary to carry document metadata
- 5.19. Link Module
- justification: necessary functionality for stylesheets and other features
1.1.2.
Removed Abstract Modules
- 5.3. Applet Module
- justification: already deprecated in XHTML, it's gone.
- 5.5.2. Forms Module
- justification: using XHTML Basic forms
- 5.6.1. Basic Tables Module
- justification: no table support in interchange (basic tables, perhaps?)
- 5.6.2. Tables Module
- justification: no table support in interchange (basic tables, perhaps?)
- 5.8. Client-side Image Map Module
- justification: no typical way for authors to edit this in wiki. OTOH, it's simply a syntax
construct for linking, supported natively by almost all browsers.
- 5.9. Server-side Image Map Module
- justification: no expected support in most wiki applications
- 5.10. Object Module
- justification: no support for applet or objects in interchange for lack of interoperability
guarantees and difficulty in cross-OS/browser/application consistency
- 5.11. Frames Module
- justification: no support for frames in interchange. Accessibility, model deficiency, lack
of interoperability guarantees and difficulty in cross-OS/browser/application consistency
- 5.12. Target Module
- justification: see frames
- 5.13. Iframe Module
- justification: see frames
- 5.14. Intrinsic Events Module
- justification: no user authoring of events markup in wiki
- 5.16. Scripting Module
- justification: no user-authored scripting supported
- 5.17. Style Sheet Module
- justification: no user-authored stylesheet content supported (document-level
stylesheets via link element)
- 5.18. Style Attribute Module
- justification: use stylesheet
- 5.20. Base Module
- justification: document base can be expressed as metadata in <meta> element. Better there than in using
base element, as we're expressing the intended location of the interchanged content, not the base of
of interchange document itself. Use recommended metadata name for this.
- 5.21. Name Identification Module
- justification: covered by 'id' attribute nowadays
- 5.22. Legacy Module
- justification: everything desirable here is possible via a stylesheet, which we do allow
1.2.
An XHTML Variant
These are based on the Modularization of XHTML Recommendation. There are three alterations
that can be made to a DTD according to the XHTML Modularization spec:
- Subset
- a strict subset includes fewer language components than the original, with no new
or otherwise altered components
- Extension
- an extension adds language components, generally within a new namespace (if we're
following the rules). A strict extension removes none.
- Variant
- a variant is both a subset and an extension, and may also alter existing elements.
Subclasses are easy and browser support is not a question. Extensions are difficult and browser
support must be provided by alternative means (e.g., scripting). When variants impose no new
requirements on browsers they are relatively safe, though not entirely predictable if others
have similarly modified their web documents. But given that most web content is not valid, this
doesn't seem like a great risk.
IWML is an XHTML variant, based on a subset. The places where IWML varies from XHTML are in
areas that have (in theory, anyway) no impact on visual presentation. IOW, all changes from
the subset of XHTML to IWML are invisible to browsers, and are generally included for things
like metadata storage, additional link semantics or metadata, and in one case, presentational
hinting (which in wiki are actually semantic, e.g., blank lines are not just whitespace, they
are paragraph breaks).
1.2.1.
Specific Variations
- <meta> everywhere.
- Well, not everywhere, but lots of good places. The <meta> element in XHTML is permitted content
in the <head> element, and provides metadata about the document itself. In IWML, the <meta> element
is itself unchanged, but is now permitted as block-level content anywhere within <body>. The
meaning of this is that the metadata contained within any <meta> element found within the descendants
of <body> is considered to apply to its parent element. E.g.,
<p>
<meta name="DC.creator" content="Murray Altheim" />
This paragraph was authored by me.
</p>
In the above example, the <meta> element states that the particular paragraph has a Dublin Core
metadata "creator" of "Murray Altheim".
Note: for Dublin Core (DC) based metadata to have a declared namespace (i.e., machine validity),
a link declaring the "DC" prefix is necessary.
See
http://dublincore.org/documents/dcq-html/ for more
information.
- 'xml:space' attribute.
- The 'xml:space' attribute is now included on any elements that may
need to specify preserving internal whitespace. This includes all block-level container elements.
- Roles on Links
- Actually, this is not an extension per se. The 'rel' and 'rev' attributes
available on <a> provide semantics for inbound and outbound links. These actually provide more
leverage (in a sense) than the single 'xlink:role' attribute on XLink's simple a-links, given
that there are two of them. Some specific roles (using a namespacing scheme similar to use of
Dublin Core (as 'DC.xxxxx' within <meta>) is suggested.
- XML Namespace.
- This specification does not use any new XML Namespace, but does declare
a wiki namespace for the purposes of reserving it for possible future use. No such use is
currently suggested by this specification.
