[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: To namespace or not to Namespace ....

• From: Max Toro <maxtoroq@gmail.com>
• To: Michael Kay <mike@saxonica.com>
• Date: Fri, 9 Apr 2010 17:49:14 -0400

> (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.

So, users that are not confused shouldn't worry about namespaces? The
problems don't seem too big for such a bad design.
--
Max

2010/4/9 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.
>> (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.
> The two fundamental problems with namespaces, I think, are
>

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

• Follow-Ups:
  • RE: To namespace or not to Namespace ....
    • From: "Michael Kay" <mike@saxonica.com>

• References:
  • To namespace or not to Namespace ....
    • From: David <dlee@calldei.com>
  • Re: To namespace or not to Namespace ....
    • From: Kendall Shaw <kshaw@kendallshaw.com>
  • Re: To namespace or not to Namespace ....
    • From: Liam R E Quin <liam@w3.org>
  • Re: To namespace or not to Namespace ....
    • From: David Carlisle <davidc@nag.co.uk>
  • Re: To namespace or not to Namespace ....
    • From: Andrew Welch <andrew.j.welch@gmail.com>
  • RE: To namespace or not to Namespace ....
    • From: "Michael Kay" <mike@saxonica.com>
  • Re: To namespace or not to Namespace ....
    • From: Max Toro <maxtoroq@gmail.com>
  • RE: To namespace or not to Namespace ....
    • From: "Michael Kay" <mike@saxonica.com>