Musing over Namespaces

David Megginson david at
Wed Dec 15 11:42:48 GMT 1999

Clark C. Evans writes:

 > Are namespaces just a modern way to handle inter-woven document
 > type definitions?

In themselves, Namespaces are pretty-much exactly equivalent to Perl
or Java packages and nothing more; they simply allow two things:

1. the ability to identify a name unambiguously in any context; and
2. the ability to avoid naming collisions.

They promise very little, then, but they certainly can form a solid
foundation for higher-order standardization efforts, like
document-type component reuse.

 > BTW, what ever happened to architectural forms
 > and how is this related? 

They can be used together.  AF's are pretty-much dead now, but there's 
much of value in them, and it may turn out that we need to resurrect
them in a year or two.

 > > Yes, and that's the natural *second* stage of standards development:
 > > first you allow innovation, then you figure out what to standardize.
 > > So you start with
 > > 
 > >   {}purchase
 > >   {}purchase
 > >   {}purchase
 > > 
 > > and then you bring everyone together for a while, bash heads, and hope 
 > > that you end up with
 > > 
 > >   {}purchase
 > > 
 > > It's messy, but it's the only standards path that really seems to
 > > work.  At least with Namespaces we can remove 50% of the messiness
 > > (there's no chance of confusing different party's extensions) on the
 > > way to standards Nirvana.
 > This sounds reasonable; where the 
 > acts like the "OED" previously mentioned...

Except that there's not a single one for everything -- it's
unreasonably difficult to maintain something like that.

 > It'd still be nice to have a single database with 
 > everyone's namespace definitions in one place though...
 > perhaps even a DTD to help describe them.  I'm sure 
 > there are organizations doing this... are there?

OASIS and Biztalk are both pushing their own schema repositories, and
there are other, less visible ones, but in the end that's not really
the way things work -- a single, central registry would be
unreasonably difficult to maintain and inflexible.

All the best,


David Megginson                 david at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list