XHTML and the Three Namespaces

[Simon St.Laurent]

Based on the subject line, this sounds like 'Goldilocks and the Three
Bears'.  I hope that we may come to a happy ending.  The last two
paragraphs of this posting are probably the most important part, for those
who just want the conclusion.

At 12:45 PM 9/21/99 -0700, Andrew Layman wrote:
>Here is my understanding of the XHTML namespace problem and its proposed
>solution:
>
>There is a vocabulary and syntax called "Strict". There is another called
>"Transitional", and it includes elements and attributes with the same names
>as those in strict, plus some additional elements and/or attributes, and the
>content models and attribute lists of Transitional are such that any
>document valid under "Strict" is also valid under "Transitional". There is
>also a third grammar called "Frameset" having a similar, superset relation
>to Transitional.
> 
>One thing that people would like is to be able to clearly define which
>documents are valid per the Strict, Transitional and Frameset rules. This is
>currently done via three DTDs.

Correct.  And in the current draft of XHTML:
[PR, section 3]
PR>This version of XHTML provides a definition of strictly conforming XHTML
PR>documents, which are restricted to tags and attributes from the XHTML
PR>namespaces.

Hence, for all documents that actually conform to this spec, we have a
DOCTYPE declaration that tells us which DTD is appropriate.

>Another thing people would like is to be able to indicate in a document
>which set of rules the document is intended to conform to. This is done by
>giving each of the three grammars a namespace, and saying that the elements
>in each namespace are to be validated against the syntax in the DTD
>corresponding to that namespace.

This is the giant leap that doesn't appear to have any substantial foundation.

1) Why would anyone want to validate XHTML fragments differently according
to the strict/transitional/frameset setup?  HTML already has a long
tradition (noted by Tim Berners-Lee in an earlier posting) of 'leave what
you don't understand alone'. If you have handlers for a particular XHTML
tag, great.  But does it matter which version of XHTML it came from?  I
seriously doubt it.  

2) Why does each grammar deserve a namespace in the context which XHTML
purports to be describing?  The DOCTYPE declaration already provides this
information.

Section 3.1.2 seems to be out of whack with the rest of the document.  If
this document is really about what it claims in 3.1, Document Conformance,
I'd suggest striking 3.1.2.

>This avoids having namespace transitions within a document (as would
>presumably occur if the Transitional namespace contained only those elements
>additive to Strict). This approach also permits each grammar/syntax to be
>described by a DTD, because we know that DTDs do not handle mixing of
>namespaces gracefully. Finally, it allows that existing HTML documents
>without any indication of namespaces, and consequently no namespace
>transitions, may be interpreted according to the broadest grammar.

We already know that DTDs don't handle namespaces gracefully.  So why pile
in three namespaces?  If for some perverse reason a developer decided to
use all three varieties of XHTML, a validating parser (XML 1.0) would
either choke on the clashing (or missing) namespaces, or face conflicts
because all three DTDs would suddenly occupy the same (internal XML 1.0)
namespace - you can't declare the same element twice...

>But it has the drawback that an element name from Strict and the matching
>element name from Transitional have different URIs, so a namespace-capable
>processor will treat them as of different element types.

Yep.  It'll make writing XSL stylesheets a lot more interesting, unless the
writers of XSLT add some kind of extra indirection for namespaces...

>The actual difference between the elements is not sustantially their
>meaning, but only their content models and attribute lists.

Which raises the question, again, of why bother validating this information
against any but the broadest DTD?  What benefit could an application get by
validating XHTML fragments, which technically aren't even described by
XHTML 1.0, against three different DTDs?

>[...example in different context...]

>Certainly, interpreting a document incorrectly because we did not read the
>relevant definitions and mappings is not attractive.  Nor is it attractive
>to label different element types indistinguishably so that the relevant
>definitions cannot be determined.

I don't think treating strict HTML as transitional for processing purposes
is 'incorrect' in any substantial way.  Nor do I think the 'relevant
definitions' in this case are worth the trouble.

>Of the alternatives that I have seen, only the proposal for three distinct
>namespaces seems to have sufficient information in it.  Perhaps I have
>overlooked a proposal that also works, but at this point I conclude that the
>burden of proof should rest with those who assert that the three namespace
>approach is faulty, and any such proof should include a demonstration of a
>workable, better alternative approach that actually solves the same problem.

The 'sufficient information' argument seems to come from a very different
valuation of that information.  To me, it's much more important to know
that an element is HTML than to know that it is strict, transitional, or
frameset HTML.  Having to work harder to find out that it is HTML in order
to accomodate the useless freight of strict/transitional/frameset doesn't
seem like a reasonable tradeoff.

I think this differing valuation is really what lies at the bottom of the
disagreement, and it shows no signs of disappearing.  In the end, whatever
the abstract arguments, I think the choice is going to be made based on
which of these 'valuations' is deemed more important.


Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.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)