Why namespaces?

[Oren Ben-Kiki]

(We'd better return this to the mailing list - could you forward it there?)

> Oren Ben-Kiki wrote:
> >
> > However, I fail to see how the application can do anything with this
parse
> > tree unless it can grab a node and ask it "who are you"? Which means, in
> > effect, it needs to perform the level 1 "areElementsTheSame" call. As
David
> > Brownell pointed out, you can't do _anything_ without this capability.
Think
> > of an XSLT processor as a sample application.
>
> The important point to note is that to *level two*, htmlstrict:P is not
> the same as htmlloose:P.

I think this might be the source of our disagreement. I claim it these two
are the same; the difference is in the DTD applied to them.

> After all, it is level two that takes advantage
> of the distinction between the two.

Only in that that one document is built according to one DTD and another
document is built according to another DTD. It is OK to have multiple DTDs
which use elements from the a shared namespace, right?

> Therefore how can level 3 go back to
> treating them as the same??

It can if _all_ the difference between the variants can be expressed in a
DTD or an XSchema. This, IMVHO, should be a design goal of XHTML - bury all
the differences between the variants in the DTD, so that the application
should stay the same. AFAIK, this was the state of affairs in the previous
draft, but that's just hearsay.

Concretely: Given an XHTML document, it might be in either LooseDTD or
StrictDTD. In both cases, the element would be named
"{html-namespace-url}p". However, the default attributes which level two
(the XML valiadting parser) assigns to this element would depend on the DTD
being used. So would the list of valid sub elements, etc.

Once this has been done by level two, level three (e.g. the XSLT processor,
or the browser) can ignore the issue. All it knows about is that an element
is an "{html-namespace-url}p", that it has a certain set of attributes
specified for it, and certain elements contained in it. What it does to this
element (e.g., if we are talking about an XSLT processor, which templates
match it; if its a browser, how to display it) does not depend on which DTD
was used in obtaining the element; it just depends on the values of the
attributes and the contained elements.

Now, I'm not saying this is the only way to do this, but I'm saying that
this is how I would like it to be done for XHTML. What I didn't see is a
simple explanation of the alternate view .I appreciate that this is hard to
do, as witnessed by me not being able to convey the above in my previous
post.

> You advocate a layered view but then claim
> that layers three and one should have the same idea of "element type
> same-ness" and layer two should have a different idea.

No; level two is simply making use of DTD specific information. That's its
job; to apply the DTD to the document so that the application will not have
to worry about DTD related issues, right? For example, the application can
trust that the structure of the document follows at least one of the
supported DTDs; it doesn't need to know what the DTD specified defaults
are - they are given to it as explicit defaults, and so on.

Maybe the problem is that you see level two as a non validating parser,
where I see a validating parser as an essential part of an XML application?

> > Again, note this is different then what happens when compiling
programming
> > languages; this information is typically encoded into the class of the
tree
> > node element. WHen dealing with XML, with don't have this option - a DOM
> > node is a DOM node, period.
>
> Actually the DOM isn't relevant. The DOM is an ugly hack. The
> Information Set is more relevant.

To my shame, I never got around to reading it. But I suspect my claim holds
there. It is in the basic nature of XML.

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)