RE: [xml-dev] To namespace or not to Namespace ....

["Michael Kay" <mike@saxonica.com>]

> I've heard that namespaces is a bad design several times, but 
> I cannot understand why it's a bad design, simply because I 
> don't know what a good design is. Namespaces is all I know, I 
> have no reason to believe it's a bad design unless someone 
> point me to a good design, are there any?

I agree, it's much easier to say what's wrong with the current design than
to propose something better. Though I don't think it would be hard to design
something better if backwards compatibility were not a constraint.

The two fundamental problems with namespaces, I think, are

(a) the overloading of attributes to act as namespace declarations. This has
little negative effect on XSLT/XQuery which ensure that the two things are
handled quite differently, but it confuses users and makes some interfaces,
like DOM, extremely messy.

(b) the confusion about whether prefixes are significant or not.

All the other complexities follow from these two bad decisions.

A simple clean design which would avoid these problems might be as follows:

(1) elements and attributes have hierarchic names, for example
org.fpml.invoice, which can always be written out in full if so desired

(2) if abbreviated names are wanted to reduce verbosity, then at the
outermost level of a document (perhaps in the internal DTD) prefixes can be
defined

<!PREFIX f = org.fpml>

allowing the element name to be written as <f:invoice>

with the clear understanding that the prefixes are for authoring convenience
only and do not form any part of the data model; they are not visible to
applications, which only see the expanded name (as a simple one-level name);
they are recognized only in element and attribute names and not in content.

If it had been done this way, I think about 30% of the complexity of our
specifications would have been avoided.

Regards,

Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay