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 ]

Joe English wrote:
> Paul Prescod wrote:
>>Anybody who is so namespace allergic that they cannot add a single
>>"xmlns" attribute to their document is, in my opinion, trying to make
>>life difficult for others, not trying to make life easy for themselves.
> In addition to writing XML documents, I also write software
> that processes those XML documents.  That's where the real
> namespace pain begins.

If you are writing software that _implements_ namespaces (e.g. a parser 
or filter or API) then I can see the problem. If you write software that 
_uses_ namespaces, I don't see it that much. Writing an XSLT for a 
document with namespaces is not much harder than writing it for one 
without. Ditto with Python.

In fact, here's what I did: I wrote a Python program that worked with 
RSS. Then I added the "xmlns attribute". Unsurprisingly, it just kept 
working because it was happy to ignore that attribute. But okay, one 
could argue that relying on the fact that the namespace was defaulted 
violates the spirit of the namespaces REC even if any decent XML toolkit 
should happily let you do so. So then I rewrote the program using full 
namespaces. The changes were straightforward and added exactly one line 
of code (the namespace declaration).

In XSLT all you need to do is add a namespace declaration and a couple 
of prefixes to your program.

Now I will happily admit that there are circumstances where namespaces 
are massively painful to code around. In particular, when you are 
implementing the infrastructure. But I submit that the case I mentioned, 
adding a namespace to a document type that *does not combine* namespaces 
is not one of them. Merely adding a namespace declarations does not make 
documents substantially harder to process...and that was the context of 
the original question. Whether namespaces are a good idea or not is 
totally separate.

 > That single "xmlns" attribute (er, namespace declaration)
 > means that the nice simple data model of elements, attributes,
 > and text turns into a vastly more complicated data model, where
 > names are <namespace-name,local-name> pairs -- or even worse,
 > <namespace-name,namespace-prefix,local-name> triplets -- instead
 > of atomic strings,

Working with tuples is not that difficult and if you hate it, tuples can 
be turned into strings (e.g.newline-separated) easily.

 > and you have to keep track of the namespace
 > environment to serialize or deserialize anything.

In a document with only one namespace the "namespace environment" is 
pretty simple. That was the context of the original question. It is the 
OPers _stated intention_ to use namespaces when vocabularies are mixed. 
So the question is what is the cost of also doing so when there is a 
single namespace. Not much.

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.

Here are the Python and XSLT examples:

from xml.dom import minidom

def countTitleWords(dom):
	items = dom.getElementsByTagName("item")
	for item in items:
		title = item.getElementsByTagName("title")[0]
		words = len(title.firstChild.nodeValue.split())
		newel = dom.createElement("words")
	print dom.toxml()



rssURI = "http://www/rss";

def countTitleWordsNS(dom):
	items = dom.getElementsByTagNameNS(rssURI, "item")
	for item in items:
		title = item.getElementsByTagNameNS(rssURI, "title")[0]
		words = len(title.firstChild.nodeValue.split())
		newel = dom.createElementNS(rssURI, "words")
	print dom.toxml()


<?xml version="1.0"?>
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; version="1.0">
     <xsl:template match="rss:item" priority="5" >

     <xsl:template match="@*|node()" priority="2">
         <xsl:apply-templates select="@*|node()"/>


  Paul Prescod


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

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