XML Applications, XHTML, and XML GL

Some comments on XML GL and its relationship to XHTML, and the future
path of hypermedia XML applications.

When applying the XML GL to variants of languages such as XHTML, it is
apparent that XML GL is excellent in achieving it's aim facilitate the
construction of accessible languages whilst building them, rather than
to check that a language is accessible once you have written it. I've
been doing this as a hands on "learn-as-you-go" development, not as
some gedankenexperiment, although there have been some conceptual
issues along the way.

There are some general issues that I'd like to address here; some of
them are related to XHTML and its future w.r.t. accessibility and
interoperability, and some have to do with XML GL.

[Abstract:] We know that the future of XHTML is something which hangs
in the balance; in the balance of producing a clean language,
producing it in time, bureaucracy and politics, and getting
implementations. Time and politics are necessary but spin offs of the
real work, which is the theory and the practice.

[Implementations:] I'm not sure what the future of XHTML 2.0 is going
to be as far as these are both concerned, but I think would be useful
for someone to start putting a finger on it; you can't review a
language if you don't know what it's for. We understand that 2.0 will
not be backwards compatible with previous versions of XHTML, and
therefore, two implementations spring up:-

1) Transformation into known languages
2) Rendering by new user agents

The second is something that takes corporate might and lengthy
nurturing periods (politics and time again!), but the first is
something that can almost be handled on a grass roots, server side
level. Rendering by new agent can, however, have the power to bring a
markup language to the next level: it is often impossible to transform
complex new behavioural structures where these functionalities are not
currently present.

[Details:] For example, let's say that XHTML 2.0 handles XInclude. It
is not possible to transform this with, say, XSLT is a totally
backwards-compatible fashion. You can hack it, by turning the XInclude
into a hyperlink, but you'd lose the parsing aspect of the include,
i.e. text/xml. You can't link to some content and force the browser to
download it as text/plain (or can you set the MIME type on <a>? Does
anyone know if this or the HTTP return header takes precedence?).

So, an XHTML 2.0-like language is going to have to be transcendent -
to break the current preconceptions that we have about markup
languages. For a start, the actual structure of the language, and the
models, are very important. But, we can always rely upon some LCDs -
text rendering (not necessarily to screen), hyperlinks, and (possibly)
multimedia. XHTML 2.0 should provide a framework that incorporates the
latest XML-Suite technologies, but forces people to create a
*semantic* and presentation free framework. It must no longer be
possible to abuse markup.

So, down to the real details. The first consideration is the document
structure - I submit that all XHTML-type documents consist of little
more than metadata and data, and that the metadata are inextricably
*linked* to the data. A basic document structure must allow for this,
but must not confuse the two. This is something that HTML 4.01 is
remarkably good at - only elements such as <address> are in the wrong
place, and there is a real lack of proper metadata mechanisms, but
otherwise, it's quite good. Note that when I say metadata mechanisms,
I mean linear/documentation mechanisms, not DLGs, although there
should always be hints to produce DLGs and so forth. In documentation,
the order of the markup is important.

The next layer is basic text. The flow/block/inline distinction in
HTML is a crock - the useful distinctions are semantics through
recursivity and extensibility. Can an element nest recursively, and
can it be extended? The proposed <section> element is an example of a
semantically extensible, recursively nesting element. <h> is a non
recursive, non semantically extensible element. You always need to
have proper hierarchies of element types - if <h> is non extensible,
then what are its semantics a refinement of? Create a new tag. Let
people extend that, just as you have for <h>. This is a markup axiom,
and is something that should be encoded into XML GL - something like
"allow extensible types, and show your strictly typed semantic
elements as being a refinement of a certain hierarchy of types". This
is the area in which XHTML 1.0 is most lacking, IMO.

You'll find that by implementing a refinement system (which was
actually brought to my attention by Aaron Swartz), you'll be able to
come up with much more meaningful semantics, and a very neat
structure. For example, in our hands on implementation, I decided that
<ul> is an oxymoron, and should just be "list". All other lists are a
sub type of that one type of "list". This type should nest
recursively, allowing for sub types that don't - simple lists.

Next comes the multimedia type content. As we have already noted:-

[[[
1.1.1 Provide unconstrained mechanisms for semantically associating
content of different modalities with one another. That is to say, if
the semantics of part of a document instance are unlikely to be
accessible to all of your readers, provide equivalent alternatives
which facilitate understanding by other means.
]]] - http://www.w3.org/WAI/PF/XML/gl-20010619

This was very fun to put into practice: I found that if you give
people to much freedom, it can lead to anarchy due to there being five
different ways to associate content, with no clear semantics to either
mechanism. That's a mess. What you should do (and what XHTML 2.0 etc.
should be doing) is to provide some standard XLink type elements, and
then to create use cases. The axiom is: "all types of content that
aren't native to your language should be *linked* to (providing
equivalence mechanisms) as naturally as possible".

Multimedia is always linked from content, but the mechanisms for
proving alternatives are not so clear. I favour linking to a <switch>,
providing roles to denote to the browser that the linked content is an
equivalence mechanism. This could be in a local or remote file: where
links are concerned, it doesn't matter. The same goes for metadata,
and this is a common error, and another thing that needs going in XML
GL: "provide explicitly scoped linking mechanisms that can import
metadata and data that are related to the document where appropriate".
Once again, XHTML lets us down very badly in this department. It
should be possible to store overviews of documents in a separate file,
and reuse a multimedia <switch> like element from one document in
another, and so on.

Two other things that I noticed in applying XML GL to a rich
hypermedia content language:- 1), providing example of how your
language can comply to WCAG and the other WAI guidelines is actually
pretty tedious, and may put some people off if we don't give simple
instructions and so forth. And secondly, the "don't infer element
semantics from names" is a good checkpoint, but it applies to the
implementors, not the creators. The reverse would be "don't create
element names that might mislead people".

So, in conclusion, XHTML can progress from being YADF (yet another
document format) to a suite of extensible suite of modules that
provide a typed hierarchy, as well as allowing for strict but flexible
content models to dispel ambiguity. Could it be any other way? :-)

[N.B. We may release our "hands-on development" once the issues are
resolved.]

XML GL is a good guide for creating such languages, but is already a
subsumption of the full construction process: we need to add
guidelines about extensibility and so forth, whilst noting that there
are some thing that we can't "guide" such as the transformability of
behavioural mechanisms.

P.S./N.B. The CC'd wai-tech-comments list is a *public* list.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://webns.net/roughterms/> .
:Sean :hasHomepage <http://purl.org/net/sbp/> .

Received on Friday, 22 June 2001 19:52:16 UTC