xml-dev - Re: ATTN: Please comment on XHTML (before it's too late)

[Paul Prescod <paul@prescod.net>]

David Megginson wrote:
> 
> It's going to be brutal just getting people to create well-formed
> XHTML documents and to include the Namespace declaration; getting
> software developers to recognize all three XHTML Namespaces (even if
> doing so requires only a three lines of code) will be all the more
> difficult, and introduces three times the opportunity for bugs and for
> interoperability problems because of omissions.

Adding three lines of code introduces the opportunity for three times
the bugs in a real application? I don't buy it. Looking for "HTML 4.0
strict" OR "HTML 4.0 frameset" is no harder than looking for "UL" OR
"OL", if the software is set up right.

And it is *just as necessary in the general case*. There will be tons of
code that needs to work the same across "similar" element types across
namespaces.

> This will be the third time that I've mentioned that I agree that some
> sort of versioning is useful.  Most processors won't care most of the
> time, so the versioning shouldn't take a form that makes their life
> harder, but what's wrong with a 'version' attribute in the HTML
> Namespace?  Processors that don't need it can ignore it, and those
> that do need it can still get the information they need.

Your presumption is that most processors won't need it. My presumption
is that most processors WILL need it. If you don't know that you are
dealing with some future version of HTML, you also don't know if your
code will work or crash. In the old HTML world we were content to fudge
it but in the new XHTML world we are supposed to be doing things in a
robust manner.

I think that we are both half right. Most software will not check the
version number on the presumption that they do not need it and then they
will silently fail when new versions of XHTML come around as many HTML
3.2 apps silently failed on HTML 4. That's the sociological problem. 

The technical problem with the version number solution is that it is
HTML-specific. When I do a query to return nodes for processing, I need
*in general* to know the types and versions of the element types of
elements so that I know what I can expect as content and attributes.
That means that I need a pervasive concept of element type versions. We
could add this to XPath and XSL but eventually Occam's razor kicks in:
how is the relationship between incompatible versions of HTML really
different than the relationship between the relationship between Cold
Fusion ML and DTML different than that between HTML 5.x and 4.x.

In general, I need infrastructure that handles new versions without
breaking old code. Backwards compatibility is arguably the most
pervasive, persistent problem in XML system design.

 Paul Prescod

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)