ATTN: Please comment on XHTML (before it's too late)

[David Megginson]

W. Eliot Kimber writes:

 > > 1. It is necessary to perform three tests rather than one to identify
 > >    a name from XHTML: that means three separate patterns in XSL (for
 > >    example), three separate contexts in a context-sensitive search
 > >    engine, three separate XML queries, three separate XPointers,
 > >    etc. etc.
 > 
 > I think that points up a general failure with the architecture:
 > what you really want to do is match things based on their base
 > semantic binding, not on their local name. Namespaces don't (and
 > can't) do that. If there was an explicit ns-to-semantic-definition
 > binding, it wouldn't be a problem, because you could establish
 > clear and machine-understandable type hierarchies and process in
 > terms of any point in the hierarchy.
 >
 > But that requires a lot of machinery, which is probably beyond the
 > W3C to define at this point in time.

The definition is not the problem -- the implementation and deployment
is.  Any standard that requires the processing of a large schema to
make sense of a small XML document will probably fail.  

XML Namespaces cannot work the same way as classes and interfaces in a
closed system -- all of the useful information (or at least enough of
it for processing) *has* to be in the document instance itself, not in
a separate schema that might reference another schema that might
reference another schema, etc.  That means that a Namespace URI is a
lot like a domain name -- a single, well-known public identity for a
collection of markup definitions -- and not very much like a class.

 > It also points up a problem with simple-minded processors that make
 > assumptions about local names that are not justified.  

Simple wins, complex loses.  I remember avidly reading the literature
about the complex experimental hypertext systems of the late '80s and
early '90s, but they lost and HTML won.  Now, maybe HTML was a little
too far on the stupid side, but not so far that it couldn't mop the
floor with the competition.  

SAX 1.0 is widely implemented because it is simple: everyone has one
or two more things they'd like to see in SAX, but since everyone's one 
or two more things are different, SAX would have become quite complex
if it had tried to accomodate all of them, and probably no one would
have implemented it.

 > A request like this, while probably reasonable on practical grounds
 > (which I don't dispute) cannot be justified on practical grounds
 > alone--there are clearly important architectural issues that this
 > problem is exposing that need to be resolved. Once those architectural
 > problems are resolved, then the appropriate practical solution should be
 > obvious (or at least easily developed).

Architecture in a closed system (like a single company or
supply-chain) can evolve top-down, just as a single company can
reasonably hope formulate and follow a business plan.

Architecture in an open system (like the Web) has to evolve bottom up, 
just as successful economies tend to develop despite government
intervention rather than because of it.

In other words, when you move to the macro level, all of the rules
change.

 > >    All of this means three times the opportunity for bugs and
 > >    interoperability problems (and yet more accusations that the W3C
 > >    cannot create specs that work together).
 > 
 > I think it's a little too late for the last one.

At least we can keep trying.

 > I'm sure that versioning is a big problem. And I'm sure that whether you
 > use one ns per version or three doesn't really matter: the nature and
 > severity of the problem are the same. Or rather: if you can manage one
 > ns/version you can manage three and if you can't manage three, you
 > probably can't manage one.

Bingo.  I believe that there should be just one XHTML Namespace as
long as possible, just as a company should stick with the same domain
name.  


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)