W3C home > Mailing lists > Public > www-html-editor@w3.org > January to March 1999

XHTML -- Namespaces

From: David Brownell <db@Eng.Sun.COM>
Date: Mon, 1 Mar 1999 09:49:11 -0800
Message-ID: <090901be640b$d1b6f980$6500000a@xenon.brownell.org>
To: <www-html-editor@w3.org>
Cc: <murray.altheim@Eng.Sun.COM>
[ I suspect the formatting here will be garbaged, apologies in
advance ... this mailer refuses to display fixed width fonts, so
I can't tell what it's really doing! ]

WD-html-in-xml-19990224 section 3.1, bullet 3 states:

  The root element of the document must designate one of 
  three defined namespaces by using the xmlns attribute. The
  namespace designated must match that of the DTD that the
  document purports to validate against.
  The defined namespaces are:
    - http://www.w3.org/Profiles/xhtml1-strict.dtd
    - http://www.w3.org/Profiles/xhtml1-transitional.dtd
    - http://www.w3.org/Profiles/xhtml1-frameset.dtd

This doesn't match the way that XML namespace URIs have been
defined to be used:  purely as identifiers, not as places to hold any
definition/declaration.  The identifier in this case should represent
XHTML itself, not some particular DTD/Schema configuration.

In short, the consequence of this (mis)use of XML Namespaces is
that XHTML elements can't usefully be mixed with anything else,
since it conflates two orthogonal aspects:  (a) validation against
some DTD/Schema rules, and (b) identification of semantics.

The preferred fix is to say that each element must have a single
specified XHTML namespace, and that validation rules (affecting
 how XHTML elements/attributes are combined with others) are
 entirely separate ... e.g. in a <!DOCTYPE ...> declaration, or
some other schema specifier.

At slightly more length, consider a common element such as UL.
Now, it is natural to want to use that in other software, such as
a TO-DO list, which may not support most other XHTML facilities.

If such software can recognize a single distinguished namespace
URI, then it can know what to do with the UL ... though it may
have a variety of representations, including one pager screen per
item.  Such logic is straightforward, and extends for any other type
of element in any other specialized namespace.

On the other hand, the precedent being set by this use of XML
namespaces is to make each potential combination of element
vocabularies -- rather than each vocabulary, e.g. XHTML, SMIL, CBL,
and so on -- have a different namespace.  Such a factorial explosion
is very bad to design into a base architecture.  When ten different
vocabularies can be combined, almost four million namespace
URIs would need to be defined!

That hypothetical pager just wouldn't have enough power to deal
with all of the potential element combinations that will be coming,
and frankly neither will the servers it talks with, either.  (This is an
issue with the namespace usage, not with hardware!)

One of the main requirements for XHTML over time will be that
its element vocabulary be easily combined with vocabularies that
are specialized for other tasks.  That is, it must be extensible and
portable ... but this proposed misuse of XML namespaces says to
me that it'd not be XHTML which could do this!

- Dave
Received on Monday, 1 March 1999 12:53:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:44 GMT