XHTML and the Three Namespaces

[Arjun Ray]

On Tue, 21 Sep 1999, Andrew Layman wrote:

> There is a vocabulary and syntax called "Strict". There is another
> called "Transitional", [...] There is also a third grammar called
> "Frameset" having a similar, superset relation to Transitional. 

As a formal spec, HTML arrived at its present state by agglomeration and
accretion.  Practically all of "HTML as an SGML application" has been a
more or less inspired process of retro-fitting.  At some point, trying to
smooth out all the lumps in a single bag of potatoes proved too scholastic
for anyone's taste, so Where There Was One There Became Three.  The fact
remains that for Joe HomePager there's still only one HTML as a concept,
and the browser(s) that are -ahem- installed on JHP's computer system have
yet to show any sign of disagreeing with that common sense notion.

> 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.

> 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. 

Syntax is already taken care of by the DTDs (to the extent that anyone
could care when it comes to HTML.)  So these "rules" must be different. 
If they're semantic in nature, then again the original point applies: as
far as the HTML spec goes, HTML is for all practical, sensible, and widely
accepted purposes a "single language" semantically.  

> 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 not a statement about documents.  It begs the question of how
"elements in each namespace" came to co-exist to begin with, and is thus
an implicit assertion about "rules applied to fragments", quite in
contrast to the first sentence of the same paragraph, repeated here:

> 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. 

The relation between 'set of rules' and 'the document' is singular to
singular.  Especially in view of:

> This avoids having namespace transitions within a document (as would
> presumably occur if the Transitional namespace contained only those
> elements additive to Strict).

How did we suddenly leap into a world of "namespace transitions"?

> Here is a provisional phrasing of the problem we need to solve: How can
> we reliably distinguish elements requiring slightly different
> processing, while at the same time permitting them to be processed
> similarly to the degree that the differences do not matter? 

What's wrong with a distinguished attribute?  For instance, this is
precisely the mechanism invoked for CSS, insofar as CLASS is "special". 
(The HTML-CSS nexus would be more solid if there were a machine-readable
way to indicate that the name of the "CSS-special" attribute is indeed
"CLASS" rather than "FOO", but even without this the fact remains that
processing distinctions on the basis of an asserted attribute value are
*already* proven current practice.) 

I might add that if *this* is indeed the statement of the problem, then
David Durand's attribute-based proposals to the SIG completely solved it.

>   <a:X> <Y/> <Z/> </a:X>
> [vs]
>   <b:X> <Y/> <Z/> </b:X>
> 
> [...] We intend that, in nearly all respects, a:X and b:X are processed
> as equivalent. 

This is an assertion about semantic intent.  Nothing prevents an
application from treating, by design, an element type "FOO" and another
element type "BAR" equivalently, whether across the board or contextually
constrained.

> At the same time, b:X in another instance document could appear as
> 
>   <b:X> <Y/> <Z/> <W/> </b:X>
> 
> The content model of b:X permits subelements not permitted in a:X.

Why does this have any bearing on the first decision to treat FOO (read
a:X) and BAR (read b:X) equivalently?  Either the application (as an
instantiation of a designer/programmer's intent) knows *why* it's doing
what it's doing, or it doesn't. 

> >From this I conclude that if we had a way to declare the extended content
> model of B as an extension of that of A, then we would be able to express,
> in a machine-readable form, the relation between b:X and a:X.

Why wouldn't the optionality of W in the content model for BAR (read b:X -
I'm resisting the "persuasive definition" impact of the syntax actually
used here) express the constraints completely?

> 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, 

For now, simply avoid statements about namespaces altogether.


Arjun


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)