Lists Home |
Date Index |
- From: Marc.McDonald@Design-Intelligence.com
- To: email@example.com, firstname.lastname@example.org
- Date: Mon, 7 Jun 1999 18:21:12 -0700
Steven Newcomb wrote:
What, exactly, is the nature of the real-world problem that
are the key to solving? Namespaces are still *perceived* as
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
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
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
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
* 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
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
* 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
This gives you architecture functionality without modifying document content
in any way. It is trying to do everything in the document that creates the
Marc B McDonald
Principal Software Scientist
Design Intelligence, Inc
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)