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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Vocabulary Combination and optional namespaces

[ Lists Home | Date Index | Thread Index ]

Arjun Ray wrote:
 > | Paul Prescod:
> | And anyhow, it should be the responsibility of infrastructure to track 
> | the namespace environment. XSLT is an example of infrastructure that 
> | does a pretty good job.
> But your Python code was exposed to the problem even in the simple case.
> I'll grant that the changes were simple, but why did anything have to be
> changed at all?

The programming problem boils down to this. In a non-namespaceed 
world, XML elements are self-contained:


In other words, XML elements are strings, after a kind. In a 
namespaced world, they are not:

  elementname, namespace, elementprefix

In other words namespaced elements are tuples after a kind. You're 
told to only care about the first two members, but sometimes you do 
need to care about the prefix (that prefixes have no import is a 
myth, because XPath makes it a myth)

For a direct example of how the structural issues of using a tuple 
affect code, see the SAX startElement call, and try operating on 
various bits of markup with a handler. For anyone that has Dave 
Brownell's SAX book, he has a good discussion on this. Or go through 
the xml-dev archives..

After that try programming with XPaths against namespaces - the sort 
of code simplicity Paul is after will be awkward with XPaths. Using 
an XPath is almost always preferreable to rolling out yet another 
DOM iterator or SAX stack or some hokey findByFoo API call - until 
it comes to using namespaces, where managing embedded prefixes can 
make a NodeList look decidely attractive. Try something like Xalan 
or Pyana with and without namespaces to get an idea of the differences.

All the while ask yourself, how to I manage this code with and 
without namespaces? How do I get the code under control?

In turns out that you can't without incurring a development cost. 
After dealing with this stuff for the last few years, I believe that 
cost isn't worth it, and where it might be worth it, it's proabably 
for corner cases that have no business being generalized into the 
bulk of programming work with XML. So naturally when I see someone 
coming at me with document design using namespaces, I'm want to 
resist that design in favour of something simple and cost-effective.

There is no canonical (self-describing) form for for a namespaced 
element, ie there is no way to treat it like a regular XML name so 
the code reflects the difference. You can't get to such a form for a 
namespaced element for two reasons

  - technically the XML grammar won't allow it.

  - socially, it seems people don't want deal with URIs as element 
names at the syntax level.

The first one is something of a show stopper in terms of code 
management. The second one is entirely understandable, but you pay a 
cost for the managing abbreviated forms. Either way you have to 
infer a namespaced element's true name, since it's not directly 
declared in the markup any more. To my mind this tacit name is less 
self-describing than a regular element name. XML Namespaces are not 
without irony.

The namespace tax isn't offering anything. My position on working 
with XML Namespaces in sofware is analogous to a RESTafarian's 
position on SOAP-RPC - why on earth would you want to tunnel like 
that? The differnce is that XML Namespaces tunnel nouns through 
markup and SOAP-RPC tunnels verbs through protocols. To claim 
they're simple and should be no cause for concern is wrong and 
irrelevant. That position won't be changing until someone shows me 
either that namespaces are neccessary in the general case (I'm 
wrong) or XML grammar is changed to allow URIs are element names 
(XML is wrong).

Bill de hÓra


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

Copyright 2001 XML.org. This site is hosted by OASIS