Article:		XML Namespaces Don't Need URIs
Subject:		Namespace prefix registry
Date:		2005-04-14 17:01:14
From:		mikeday
Hi Bryan, I did not mention the idea of a namespace prefix registry in the article because I don't believe that such a thing would be necessary -- it certainly would not be very practical to implement. The example I gave of using XSLT with namespace prefixes and no namespace URIs does not need a namespace registry in order for the XSLT processor to function correctly, which is worth keeping in mind. I think that the perceived need for a namespace registry and for unique namespace URIs is based on the misconception that every element name must be globally unique in every circumstance or software won't know what to do. In practice, XML processing software usually has more contextual information available to it than just the element names, and disambiguation can be based on context, position, attributes and so on rather than making names globally unique. Best regards, Michael

Previous Message

Next Message

• Namespace prefix registry
  2005-04-15 06:08:15 bryan rasmussen [Reply]
  
  I'm not sure what you mean by this, if you mean that prefixes should have a hardcoded association then obviously you could not maintain that for every namespace, so you would just want to do it for the important namespaces (I suppose that is a reasonable way of defining these namespaces you refer to in the article) some problems arise

  
  1. parsers must now support a list of prefixes that don't need to have a namespace associated with them. how does one make sure that parsers maintain the same list
  2. people will be fighting to get their namespace on the list of important namespaces
  3. one of the problems with namespaces is that they confuse newbies, the idea of having pre-established prefixes and then prefixes that are not pre-established would be highly confusing in itself.
  4. If the idea is not to have a list then I guess you're just saying that there is no need for namespacing whatsoever. I could agree with that in relation to the scenario for their usage put forward in the spec but not in the context of how they are actually used.