OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Do namespaces address all use cases well


I may give at least an example of something that we (developers) have lots of problems to get, it is the defaut attribute namespace.

The XML specification is :
"A default namespace declaration applies to all unprefixed element names within its scope. Default namespace declarations do not apply directly to attribute names; the interpretation of unprefixed attributes is determined by the element on which they appear.

If there is a default namespace declaration in scope, the expanded name corresponding to an unprefixed element name has the URI of the default namespace as its namespace name. If there is no default namespace declaration in scope, the namespace name has no value. The namespace name for an unprefixed attribute name always has no value. In all cases, the local name is local part (which is of course the same as the unprefixed name itself). "

The 1st paragraph does not say a lot as you can see...

The 2nd paragraph says that unprefixed attribute has no namespace (you get null with APIs). That is a trick that is useless for me. I think that attributes namespaces should be processed same way that a child element.

In my opinion, namespaces should be done as packages in a language like python, or java, meaning that it is a shortcut for a longer element name.
Instead of writing :

you import a namepace and you associate it with a prefix with xmlns:pre="http://namespace"
and you can shortcut the above by :

or you import a default namespace and then the unprefixed markups come from that namespace.
Null namespace should not be allowed, or interpreted as being part of xml: namespace


2009/7/8 Jim Tivy <jimt@bluestream.com>

Absolutely, see my second sentence:


"For a number of use cases I have seen namespaces work.  They are integrated in most Xml processors.  So they are there already for free."


As well, we can only focus on so many things and learn so many things and the lead time on tools supporting new technolgies is 5 years or more for any kind of saturation.


But at some level, I applaud the question - can we do better?


From: COUTHURES Alain [mailto:alain.couthures@agencexml.com]
Sent: Wednesday, July 08, 2009 2:17 PM
To: Jim Tivy; 'Michael Kay'; 'Kurt Cagle'; 'XML Developers List'
Subject: Re: [xml-dev] Do namespaces address all use cases well


Even though it's always good to think about how to improve namespaces, how long would we have to wait for such a new mechanism to be widely available ? Don't we need solutions for today ?


Jim Tivy a écrit :

Interesting idea. This is likely something that has to be addressed in an Xml track.  I am not sure that HTML-5 is even an Xml track?


For a number of use cases I have seen namespaces work.  They are integrated in most Xml processors.  So they are there already for free.


But how well they address all use cases I do not know.  I would be interested to hear about use cases where Xml namespaces fail and rough sketches of better technologies.




From: Michael Kay [mailto:mike@saxonica.com]
Sent: Wednesday, July 08, 2009 1:55 PM
To: 'Kurt Cagle'; 'Jim Tivy'
Cc: 'XML Developers List'
Subject: RE: [xml-dev] XHTML 2 Working Group won't be renewed?


 > There's supposed to be an extensibility workshop in September at one of the F2Fs where namespaces in general will be hashed out - I plan to be monitoring that one carefully, as I suspect that there will be a move to "fix" namespaces in a way that will have long term negative repercussions for the XML community. 


Let's approach this positively. XML namespaces are a pretty awful piece of design. Perhaps this is an opportunity to revisit the requirement and do something a bit more elegant.



Michael Kay




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS