Namespaces are dead.

[Marc.McDonald at Design-Intelligence.com]

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 at ic.ac.uk
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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)