Why namespaces?

[Oren Ben-Kiki]

Paul Prescod <paul at prescod.net> wrote:
> If the validation layer sees two things as distinct then any layer built
> on top of the validation layer should continue to see them as distinct.
> To me that is a no-brainer. In this case the validation layer sees
> htmlloose:P and htmlstrict:P as completely different documents. To the
> validator they are as distinct as Docbook:article and xsl:stylesheet!

I think this is the source of our disagreement (I hope it is!), and -
obviously - I disagree.

The short argument is by example: Consider a C compiler. The parser
obviously distinguishes between "a[i]" and "*(a + i)". However, once the
parser is done, the rest of the compiler does not.

A different longer argument is as follows:

I have DTD1 and DTD2 which are identical except for a single default
attribute "A" value to a single element "E". In DTD1, it has a default value
of "1", in DTD2, it has a default value of "2". I have an application
working on top of a validating parser. The application accepts documents in
either DTD. Extending this to the full XHTML case is left as an exercise to
the reader :-)

I have two documents, D1 according to DTD1 and D2 according to DTD2. They
are identical except that whenever an "E" element in D1 has a "2" value in
attribute "A", the attribute is ommited in the matching "E" element in D2,
and vice versa.

The validating parser must treat "E" elements in D1 differently then "E"
elements in D2; it must attach different default values to the "A"
attribute. It follows by your argument that the application must also
distinguish between these elements.

But the output of the validating parser is _identical_ for the two
documents. The application _can't_ make this distinction.

Solution 1: the application could query the parser as to whether the
attribute is a default one or an explicitly specified one. Accepting this,
one should have no objection to using the same XHTML namespace and using
three DTDs - because the browser could ask the parser which DTD was used to
make whatever distinctions are necessary. So assuming this isn't good
enough...

Solution 2: It is illegal to write applications which accept more then one
DTD. This rules our XSLT processors, browsers, search engines, XML pretty
printers, etc. Obviously unacceptable. It is a cope out, anyway; it renders
the whole issue of distnguishing between two "things" moot.

Solution 3: It is illegal to have two DTDs which contain the same
"{namespace}element". Now, you could go this way. Make a 1-1 mapping between
namespaces and DTDs. It has its advantages. If we go this way, some things
would be simpler. For example, the namespace URL could be that for the DTD,
and so on. I personally don't like this, and the current W3C recommendations
take great care not to imply this conclusion. So, we are left with:

Solution 4: Give up on this requirement. It _is_ possible for the validating
parser to make distinctions which are invisible to the application. Now,
what is so bad about that? After all, why _should_ the application care?

Solution 5: None that I can think of at the moment, but maybe you can?

<WildSpeculation>
BTW, while writing this, I hit upon a notion on why the W3C XHTML WG would
specify three namespaces into XHTML. (Second guessing comitees is a fun game
:-) Assume that they don't want to make a decision wrt. solution 3. This is
reasonable; it isn't their mandate, after all - they are concerned with
XHTML, not namespaces and DTDs. If they forced the issue, they would suffer
justified critisism from whoever holds the opposing view.

So, if they release XHTML with one namespace, they are forcing the issue.
You'd have to specify multiple DTDs for a single namespace. Oops. But, if
they specify three namespaces, they avoid the issue. Whetever is decided in
the future, they are safe. All very reasonable up to a point.

But this is wrong. It means that until this is decided, we'll see a
proliferation of namespaces invented just to avoid this decision. It would
then cause momentum in favor of accepting solution 3 - all these
multi-namespace recommendations would look pretty bad if it was rejected.
And implementations would probably be built making this assumptions in some
level. So, this is imply another way of forcing the issue. I wouldn't have
minded much if it didn't force it in the wrong direction :-)

How about someone simply making a decision on this? If not the XHTML WG,
then some other one? And _soon_, so we could start adjusting to whatever the
decision is, instead of thinking up convoluted ways to avoid making it?
</WildSpeculation>

Have fun,

    Oren Ben-Kiki


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)