Why namespaces?

[Oren Ben-Kiki]

Paul Prescod <paul at prescod.net> wrote:
> David Megginson wrote:
> > Sure -- that's why you have a DOCTYPE declaration at the top, so that
> > validating processors can check the HTML against a DTD.
>
> This raises a major question about the utility of namespaces in a
> vocabulary that cannot be mixed with other vocabularies. What does the
> namespace add that you can't get from the doctype?
>
> And when we CAN mix XHTML with other vocabularies the precise details of
> the namespace will be vital for proper validation! So multiple
> namespaces will be necessary.

I would presume that to mix XHTML with/inside another namespace, one would
need to create a DTD for the "mixed" document that would somehow refer to
(parts of) the XHTML DTD. It would then depend on which DTD variant he
refers to, instead of on the namespace. Of course one can't do this sort of
trick today with DTDs, but it might be possible with XSchemas, at least some
day.

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

So far, I've seen no reason to abandon this view as a guide; it has obvious
advantages and no serious disadvantages I can see. I quickly found out,
typically by implication, that this view is not shared by others - some of
whom I hesitate to disagree with without a very good reason. However, it is
hard to figure out the exact "world view" of someone just by his position on
a specific issue, so I don't have a clear grasp of a coherent alternative
view. I'd greatly appreciate it if someone posted one; it is hard to
disagree with someone you don't fully understand :-)

What unsettles me is that I can't figure out the W3C view on the matter. The
namespaces spec, for example, seems to follow the above view. The proposed
XHTML recommendation obviously doesn't. It could be that there are differing
views within the W3C itself. Of course this could be just my ignorance
speaking, but I doubt that. If there was a clear decision on the overall
view, the debate would have been on whether the W3C view is right or wrong,
not whether feature X should be this way or that (the chances of there not
being a debate at all are pretty slim :-)

So, anyone care to make a crack at defining, in one or two paragraphs, an
alternative view? And/or refer me to some W3C paper which clarifies what the
"official view" is? Then we could start arguing - sorry, debating - about
the core concepts instead of about each new feature as it appears in each
new recommendation. After all, if there's no clear decision about this, we'd
end up with features pulling XML in different directions - not a recipe for
a healthy standard.

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)