RE: Namespaces are dead.
Steven Newcomb wrote: What, exactly, is the nature of the real-world problem that namespaces are the key to solving? Namespaces are still *perceived* as solving, and are often *sold* as solving, a problem that they do not in fact solve: the problem of allowing information to be exchanged in a truly open marketplace. Namespaces are being sold as the key to interchanging e-commerce information. And they will work for that purpose, BUT NOT IN A VENDOR-NEUTRAL CONTEXT, in which every system vendor can participate on a level playing field with every other system vendor, with a reasonable expectation that information will be reliably interchanged, regardless of who made the software that produces or applies the information. The problem Namespaces solve is ambiguity - the same name means different things. As Steven noted, that results in the creations of private islands of names. The problem architectures solve is synonym - the same meaning has a different name in the context of the architecture. To me, the problem with architectures is not their concept but their implementation: * If they are to work with well-formed but not valid documents, each element needs its mapping declaration attribute which is quite verbose and means a document must change with the addition of a new architecture. * If they are restricted to valid documents, then the architecture mapping attribute can be defaulted in the DTD and the content would not need to be changed with a new architecture (the DTD would). However, then it is restricted to validation parsers. It just breaks either way. I am viewing an architecture as the description of the expected form of some application that will use the document. It's preferable to not change a document just because there is a new consumer for it. I've suggested in the past that the problem that is trying to be solved is the re-use of documents under different organizational models (i.e. with different element labels). I see that as different applications parsing the same source document with different validation criteria. Such re-use should meet the following goals: * The content document should not reflect how it can be reused. * There should be a specification that describes how a document should be re-used. * The latter specification is associated with the consumer of the document, not the document itself. To put it plainly, the basic problem is putting document consumer information in the document. Doing so results in needing to modify every document every time a new consumer is created. Parsers need an additional mode - parse the element tree resulting from parsing a document according to a second DTD that is supplied by the application using the parser. This DTD expresses the mapping of elements ala architectures. This gives you architecture functionality without modifying document content in any way. It is trying to do everything in the document that creates the problem. Marc B McDonald Principal Software Scientist Design Intelligence, Inc www.design-intelligence.com <http://www.design-intelligence.com> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... 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@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format