[
Lists Home |
Date Index |
Thread Index
]
Title: Why make namespaces so complicated?
There are endless discussions on namespaces on this list. Those who see them as pure syntactic sugar always seem to have a problem with the idea of their URL's pointing at things. Those who see them as carrying some meaning always have a problem with the idea that they can be used for a level of validation with absolutely no knowledge of semantics and potentially not even a knowledge of the namespace rec.
One of the nice things about namespaces is the different levels they can be used at. They are ideal for creating unique name for pure XML validation purposes, but they can also be conveniently employed to identify a vocabulary, to simulate polymorphic type definitions and to imply semantics about a particular set of data structures. All of these seem perfectly valid(TM) uses of the facilities provided by the namespace rec.
RDDL would seem to be an extremely functional and very simple solution for working at several of these levels. Correct me if I'm wrong, but (arguments for late binding of namespaces and hanging types aside) the primary purpose of namespaces is to disambiguate element/attribute names (the loose binding which prefix-->namespace mapping allows seems to be an accidental side-effect resulting from XML1.0 naming rules). Which means, "What is the syntax of the element (or attribute) with this name?"
It seems pretty straightforward to me (and not highly complex) that if you can use a string for the namespace which points to a place where that syntax can be found (completely irrespective of any semantic overtones the particular element may carry), it would make a lot of sense. If you could, at the same location, provide some documentation describing how the elements and attributes within the given namespace are intended to be used or processed, then that would be an added bonus. If my computer can read and understand some of that, better still. It would also seem prudent to recognize that when people (or software) see strings that begin with http://, they toddle off onto the internet to see what's there. I personally think it is rather obtuse and mischievous to use http://anything if you're not going to be polite enough to put something at the end of it. And all that needs to be there is something which says what content this node may have. Even RDDL seems a bit overboard for this sometimes, why on earth would you use RDF?
OK, so there's nothing in the namespace rec to say that namespaceURI==vocabularyURI, or even that the namespaceURI has to be unique anywhere outside the scope within which it may be encountered, but the common sense implication is that adding a namespace to a name using a naming scheme which "guarantees" global uniqueness of that namespace identifier is done to make it unique. From my (perhaps simplistic) perspective, "globally unique" means that there's only one like it in the world. This is not the same thing as saying that the namespaceURI (or the vocabularyURI, for that matter) *needs* to be "gettable", but since we've got a mechanism, all in one handy string, which allows us to
a) uniquely identify a vocabulary and
b) uniquely identify a location on the internet where information about that vocabulary could be available,
it seems a shame to waste it. Which makes namespaceURI == vocabularyURI + RDDL an extremely sensible starting point - any other way lies madness and will require Yet Another Rec orthogonal to (or possibly parallel to) namespaces to allow unique identification of XML definitions. If there are variations or subsets of those vocabularies, there doesn't seem any reason not to put them there as well. Is this perfect? No, but it is simple and solves 80% (or more) of the problem. I guess there are those who will argue that a "vocabulary" can contain elements from many namespaces, but heck, if someone sends me a novel with some Spanish words in it, I don't expect them to be in the English dictionary.
I don't know if XHTML provides a valid argument for "namespace N:N vocabulary". That is simply an interpretation. If they are different vocabularies, perhaps they should have been given different namespaces? It seems to provide an unnecessary level of complexity to insist that adding an extra element creates a functionally distinct vocabulary - you end up creating a system that multiplies the work in the (90% of) simplest cases. As a slightly strained analogy, I could argue that the words used in physics are a different vocabulary from the set of words used to discuss philosophy, where in fact they are simply subsets of a common vocabulary (the English language). Iff I choose to discuss these things in Spanish, will I be moving into a different vocabulary (which may, as in the case of IT terminology, import certain aspects from English).
There also seems to be a pursuit of some holy grail of "reliably pointing to resources", but unfortunately you can't and never will be able to. Using PUBLIC ids instead of URIs/URLs/URCompletelyConfusedByAllTheAvailableAcronyms doesn't solve the problem in the slightest, just moves it somewhere else. Companies will go out of business or change the organization of their publicly available resources. Networks will go down and computers will do things for "no apparent reason"(TM). Hackers will spoof web sites and send viruses instead of whatever it was you really wanted.
If two people choose to use the same string for their namespace URI, tough. It can happen, learn to live with it. If I use a URI that starts with my domain name, I can be fairly sure that no one else can control what is "there"(TM), hackers notwithstanding. If I choose to use someone else's domain name, then I can hardly complain if my applications break because of it.
It is an imperfect world, learn to live with it.
John
_______________________________________________________
John Anderson
CTO BarbadosoftTM
The XML Management Company
+31 (0)20 750 7582 / +31 (0)6 55 347 448 / www.barbadosoft.com
The information transmitted by this e-mail message is intended solely for the use of the person to whom or entity to which it is addressed. The message may contain information that is privileged and confidential. Disclosure, dissemination, distribution, review, retransmission to, other use of or taking any action in reliance upon this information by anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message.
Although we have taken precautions to minimize the risk of transmitting viruses we nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by viruses.
| 