Namespaces Not Necessarily Unrepentant Evil

[W. Eliot Kimber]

All,

At the recent XML Developer's Day I made a bit of a pest of myself by
challenging the use of namespaces at every opportunity.

However, after listening to a number of people whose opinions I respect who
told me that my complaints were largely misguided and after a bit of
reflection on my own emotional reactions to the subject, I've decided that
perhaps I was not being entirely rational on the subject and that perhaps I
owe at least a partial apology to those I pestered.

First, David Megginson's XAF (XML architectural forms) implementation
demonstrates that name spaces provide a necessary facility for making
architectures generally usable in a constrained processing environment,
namely giving you a defined syntax for qualifying names for communication
to downstream processes.  In the full architectural processing model you
don't need this because the processing systems have access to all the data
and everything is maintained in its original context. However, as David
points out, this is not reasonable for typical XML processing environments
(e.g., Web browsers and server-side pipe segments).  

In putting together a system of architectures for a client, I found that it
was a practical necessity to use essentially David's XAF trick (see his
paper on XAF once it's put up wherever the XML Dev Day papers end up
getting put) to maintain knowledge of the original document's GIs in the
down-stream architectural instances. I had to do this because I know that,
at least in the short term, they'll be using non-architecture-aware
processing tools to do architecture-based processing.

The technique is a simple one: in the architecture provide an attribute
whose value is the original ("client") gi. In the client document, set the
value of the attribute to the client GI plus a prefix representing the
architecture/doctype that governs the client document.  For example, in my
target architecture I would use a declaration like this:

<!-- Declarations for "gendoc" architecture -->
...
<!ATTLIST division
  original.gi
    CDATA
    #REQUIRED
>

And in my client document's DTD I would do this:

<?xml version="1.0"?>
<!DOCTYPE mydoc [
 <!-- Connect this document to the gendoc architecture: -->
 <?IS10744 arch name="gendoc" public-id="urn:prose:gendoc architecture"?>
 
 <!ATTLIST topic
   gendoc
     NAME
     #FIXED "division"
   original.gi
     NAME
     #FIXED "mydoc:topic"
 >
]>
<mydoc>
<topic>...</topic>
</mydoc>

The "architectural instance" you get by processing the "mydoc" document in
terms of the gendoc architecture would look like this:

<gendoc>
<division original.gi="mydoc:topic">...</division>
</gendoc>

I need the architecture name prefix because different parts of a document
could come from different architectures, so just providing the original GI
is not enough--it has to be bound to its original architecture/doctype
context.  

So the idea of formalized qualified names does have real value, solving
practical problems in a standardized way. Hmmph.

BUT...

BUT...

BUT...

I still have some concerns about namespaces that I think are legitimate:

1. The use of name spaces alone does not satisfy requirements that an
architecture-like approach does satisfy. In particular, using name spaces
alone the same element type cannot be mapped to multiple taxonomic classes
at once. However, as David made so clear in his talk, most useful objects
exist in a variety of taxonomies at once and it is often useful or
necessary to be able to view an object with respect to different
classifications at the same time. Qualified GIs alone cannot do this.

2. I see some enterprises and people overselling the power of namespaces in
a way that seems to be both dangerous and irresponsible, if not downright
unethical.  For example, if I can save Word documents as XML but only if
every element type starts "msword:" then what have I gained? Not a great
deal more than I already have with RTF.  "You can have any name space you
want as long as it's black" is not an acceptable answer.

3. The effectively compulsory use of name spaces unnecessarily complicates
XML parsers and processors. One of the advantages of architecture-like
approaches is that parsers and processors need not be aware of them because
they don't modify the basic syntax of documents.  The specter of qualified
names becoming part of the base XML language frightens me.

4. Name spaces take away authorial choice of element type and attribute
names. This is not a problem when documents serve only machines, but is
unacceptable in an authoring environment.  I would like to see people who
talk about and champion the use of name spaces in place of
architecture-like mechanisms to make this clear. It's important.  

Again, my apologies to those who I badgered inappropriately. I will
endeavor in the future to reign in my emotional reaction to the subject of
name spaces and focus only on technical issues, of which there are many.

Finally, my thanks to David Megginson for doing an amazing job of putting
the name space and architecture mechanisms into a common context in which
their respective strengths and weaknesses became clearer and for providing
useful, working code for taking advantage of architectures in an
XML/namespace context.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

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/
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)