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

[Rob Koberg <rob@koberg.com>]

On Fri, Apr 9, 2010 at 1:53 PM, Michael Kay <mike@saxonica.com> wrote:
>> 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

I think, this is the problem. People are not distinguishing the real
concerns or the parser and processor developers from the users of
their products (what I think most people consider as the application
developer). I think smart people (who didn't really want to learn XML
in the first place?) grabbed onto the expressions of frustration from
the parser and processor people dealing with namespaces scattered all
over a document. They used this to show others that, hey, if these
guys say it sucks, then don't even worry about it.

For the end user, namespaces are very useful. They probably don't even
know they are working with them. For the application developer (one
step down from the parser processer dev), it might be a pain to lean a
new naming convention, but it really isn't that difficult. I think a
reasonably competent javascript developer could understand it easily
if there wasn't the easy fallback to the lower level devs completely
rational criticisms.

best,
-Rob

>
> (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
>
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>