Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] Do namespaces address all use cases well

From: "Jim Tivy" <jimt@----------.--->
To: "'nico'" <ndebeiss@-----.--->, <xml-dev@-----.---.--->
Date: 7/9/2009 9:07:00 PM
Nicely said Nico

 

I agree attributes should be in the default namespace if unqualified.

 

I think you clearly described a sort of name lookup - perhaps based on path
- to resolve which namespace a name belongs to.  I am nervous about
proposing a model that requires more processing to know what namespace
something is in.  As well, without tools I would not know which namespace an
element was actually in.  Explicit prefixes give you the abilility to know
immediately.

 

Jim

 

  _____  

From: nico [mailto:ndebeiss@g...] 
Sent: Thursday, July 09, 2009 2:31 AM
To: Jim Tivy; xml-dev@l...
Subject: Re: [xml-dev] Do namespaces address all use cases well

 

Hello

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
<http://www.w3.org/TR/xml-names/#dt-expname>  name corresponding to an
unprefixed element name has the URI of the default
<http://www.w3.org/TR/xml-names/#dt-defaultNS>  namespace as its namespace
name <http://www.w3.org/TR/xml-names/#dt-NSName> . 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 <http://www.w3.org/TR/xml-names/#dt-localname>  name is
local <http://www.w3.org/TR/xml-names/#NT-LocalPart>  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 : 
<"http://namespace":tag>48</"http://namespace":tag>

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

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

Regards
Nico
http://debeissat.nicolas.free.fr/



2009/7/8 Jim Tivy <jimt@b...>

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@a...] 
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 ?

-Alain

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.

 

Jim

 

  _____  

From: Michael Kay [mailto:mike@s...] 
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.

 

Regards,

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

 
 

 

 

 



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent