From: "Bill de hÓra" <bill@[...].net> 

>  Does anyone have an example of a collision that can only be solved, 
>  or even best be solved with XML Namespaces? A neccessary condition 
>  is ideal, but examples where namespace represents an optimal design 
>  decision will do.  

A client has dozens of databases.  Some of these were derived from
the same ancestor database but moved to different geographic locations and
independently maintained and augmented. The semantics and
date-conventions used in commonly-named tables and fields in each database 
were not necessarily the same.  The client wants to merge the
data into a new unified database, and use XML as the interchange medium.

As a first line of defense, all the different databases are allotted
different namespaces, so there is no capacity in the XML system
for (e.g. by a programming mistake) merely copying over data from
one data: movement of data requires a change of namespace
as part of an explicit mapping.

So the abstract solution here is to adopt a two-level hierarchical name.
Even better if the upper-name is a first-class object in the system 
(i.e. one that can be manipulated by its own operations not
requiring string operations on the name, and which has a
special status.)    XML namspaces provide this.

To an extent, aguments about whether namespaces are necessary for
anything can miss the point as comprehensively as can arguments on whether
attributes, comments, PIs and entities are necessary.  Such arguments are like 
whether Java's inner classes or "protected" status or packages are necessary:
even classes are not necessary, in the sense that the power of C with no classes
is no less than the power of Java with classes, but classes provide first-class 
embodiments of the analysis used. That is all namespaces need to do:
if namespaces can provide a syntactic reflection of some useful analytical feature
they are useful for programmers as a matter of craft and prudence. 

Fielded names have a good history and are useful. Namespaces are just a
baroque, bureaucratic kind of fielded name. That namespaces are built into XSLT, 
for example, is a compelling reason to use them in most cases rather than
rolling your own fielded name.

I think some of the comments against namespaces start from the straw man that
namespaces must solve modularization problems. But that is like expecting
XML to solve data interchange problems:--a syntax is a vehicle for an analysis/solution
not the analysis/solution itself. 

The point is how to make large information systems seem like they are clear and
show that they are under control: so that names suggest and reinforce the desired 
system-analysis to programmers.  It is like my comments on quality assurance
last week: using namespaces won't guarantee fewer bugs; but they can be used
to make interfaces more explicit by grouping and separating names.
 
Cheers
Rick Jelliffe

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>