Why namespaces?

[David Brownell]

Paul Prescod wrote:
> 
> Oren Ben-Kiki 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.
> 
> 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.

Not all applications will be working with parse trees, but I'll accept
that model for this discussion.

However, I won't accept that level 1 should be a "don't care".  Consider
an XSL/T pattern match; one certainly needs to know if the element names
are the same.  And the same applies in a variety of other applications
as well:  something is actually looking at the elementnames to determine
how they get processed.  (Where the "names" are tuples with a namespace
URI and local part, of course!)


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

See above ... I won't speak for Oren, but for me that's clearly wrong.


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

Perhaps you could clarify this for me:  why would an XHTML content
model imply a stylsheet?  The need doesn't naturally follow; maybe I
missed something in one of the hundreds of earlier messages!  Code
handling the "frameset" model handles "transitional" and "strict" as
simple subsets -- right?


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

Now you're bringing validation into this.  Browsers validating?  Hmm.
It's mandatory neither in XML nor in XHTML.  I can imagine an editor
(not browser!) needing to validate, but that's just a case of testing
against a DTD or schema.  Normally, validation would be done as part
of constructing the parse tree you've assumed.

Also, XHTML 1.0 specifies XML's validity -- gotta include a doctype,
and validate against it iff you claim to validate.  So the unique
names don't really matter, it's lowercase HTML vocabulary names (with
no namespace stuff necesary).


> It would be perfectly legal and useful to make an application that only
> worked at the "lexical" level. But let's not pretend that that is the
> norm. It is not. Most applications care about the overall "parse tree"
> (content models etc.).

I really don't see why the parse tree would need to expose content
models, particularly in the case of the render-only application you
describe.

- Dave


>  Paul Prescod
>

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)