W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > June 1997

Re: Update on namespaces

From: David G. Durand <dgd@cs.bu.edu>
Date: Wed, 18 Jun 1997 16:01:04 -0500
Message-Id: <v0300780eafcdfa866018@[]>
To: w3c-sgml-wg@w3.org
At 2:21 PM -0500 6/18/97, Paul Grosso wrote:
>If you add : to namechar and then explicitly prepend every element
>name with the appropriate "namespaceid:", you have effectively created
>what you can consider to be a single new namespace in which all names
>are unique.  For any document instance in this new namespace (in which
>every name just happens to have a colon in it), there are an infinite
>number of DTDs one could write (where every element name in any of these
>DTDs just happens to have a colon in it).  In practice, I posit that
>someone with knowledge of how the various namespaces interact (e.g.,
>an ISO 12083 article document that uses CALS tables and AAP math)
>could take the various DTDs and combine them into one DTD (in which
>every name just happens to have a colon in it) that would be reasonable
>to use as the DTD against which to validate any instance that combines
>these namespaces.

I thought about this for a while, and even tried to convince myself it was
a good idea, but the tag-salad in instances that I've seen propagated under
the namespace rubric gave me significant pause. Also, the term namespace
implies something more than just a new character in names (as well as
implying special stylesheet-dispatch syntax to parse the new information).

People are proposing that there is some way to link instances of the name A
in one document with instances of the name HTML::A in another document, and
that implies more than just name uniquification, which I can do without any
special syntax, thank you. I can make unique tagnames like
<com-dynamicdiagrams-markup-para> without any work at all...

I'd rather see a solution that solved the problem of combining DTDs (we
gave up such proposals when we settled on existing DTD notation). Then you
would be getting some value out of the notation that architectural forms
would not easily give you (although if you define architectures rather than
DTDs, you might be better off).

But none of that would be a candidate for XML 1.0. My point is that there
are lots of things that people have mentioned that _could be solve_ by
_some variation_ of one of the proposals here, but we lack a fully-fleshed
proposal, or even a fully-fleshed theory for a proposal, and a clear list
of requirements in priority order. So I see standardizing a quick hack as a
potential mega-loss, because we just have to pray that we guess right.
That's acceptable for research, but bad for standardization, in my book.

>No one said that there needs to be some magic way to derive automatically
>from the constituent DTDs some DTD that properly combines the namespaces.
>DTD creation has never been magic or automatic (except in the trivial
>case of creating just a "DTD that works" for a specific instance, which
>you can still do for an instance composed from multiple namespaces), so
>why should it have to be for the namespace issue?

I don't want to be defending colons a decade from now with the words "It
seemed like a good idea at the time". If we're not sure what we're doing,
we should wait. XML is plenty useful already, so let's not take any hasty
decisions at the last minute.

  -- David

David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________
Received on Wednesday, 18 June 1997 15:56:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:10 UTC