- From: David G. Durand <dgd@cs.bu.edu>
- Date: Wed, 18 Jun 1997 16:01:04 -0500
- 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