Fw: Why namespaces?

[Oren Ben-Kiki]

Paul Prescod <paul at prescod.net> wrote:
> I wrote:
> >
> > There's so much churn going about distinguishing between three things:
> >
> > 1. Unique naming - making sure that one can call
"areElementsTheSame(name1,
> > name2)".
> > 2. Grammar/Syntax/Structure constraints - "isDocumentValid(rootElement,
> > DTD)", "addDefaultsToDocument(rootElement, DTD)".
> > 3. Semantics - doing whatever the application is for.
> >
> > I would like to think that the intention was for namespaces to live
> > exclusively in level 1 (call it "lex"), DTDs/Schemas in level 2 (call it
> > "yacc"), and level 3 is the application itself. This is maybe simplistic
but
> > I found it to be a great help in figuring out my position on some of the
> > issues raised in the relevant threads.
>
> This three level view is great. It also helps me to figure out my
> position: but it is the opposite of yours.

Aha! An alternative view! Which is, exactly? I'm afraid that the following
does not explain it to me:

> Going back to lex and yacc: once you have the parse tree you don't care
> what tokens you used to get there. The application should only look at
> level 2. It is *level 1* that it should not care about.

You lost me here. Yes, the output of level two is a complete parse tree -
that is, validated with default values expanded, and the application should
not (typically) care whether an attribute value came from a default or was
explicitly given, which namespace prefix was used for specifying the
element, and so on.

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.

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.

> Therefore I disagree with your next sentence:
>
> > In the XHTML multi-namespace issue,
> > for example, I'd rather the three XHTML variants were defined at level
2 -
> > possible sets of constraints and defaults for a document, such that the
> > application (say, the browser) should not in principle have to worry
about
> > which variant was used.

Well, I'm not sure exactly why you disagree - it boils down to not exactly
understaing your view, I guess.

> First, the browser doesn't care whether the differentiation was made at
> level 1 or 2. Using your own model, it sees only level 2.

Yes. In my view, the idea is that the difference between the variants is
only in validation and default attribute assignment. Once this is done, all
three variants are translated into a single "format"/"language"/"set of
possible trees in memory", which the browser then processes.

> Second, note that an XHTML browser *does* need to worry about what
> variant of HTML was used. The browser must decide which of its implicit
> stylesheets to apply. Each stylesheet has hard-coded knowledge of
> content models embedded within it. With HTML this is not a big deal
> because we have become used to presuming that all HTML will be "loose".

Which I claim would be simpler/better done by assigning a default "the
implicit stylesheet to use is" attribute at level 2.

> In general, as a model, we should adhere to your model strictly: the
> browser should see only level 2. Level 2 validation should be driven by
> the unique names in level 1.

Yes. I have a problem in that I agree with all your "high level" statements
but reach an opposite conclusion when it comes to concrete features. I find
it hard to pinpoint the exact issue we disagree on - is it something to do
with the in-memory data model (the DOM)? I admit that I didn't study the
DOM interfaces as I should have - I use SAX for all my applications.

Share & Enjoy,

    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)