[XML-SIG] Namespace support for DOM

Paul prescod@prescod.net
Mon, 28 Dec 1998 08:01:43 -0600 (CST)


On Sun, 27 Dec 1998, A.M. Kuchling wrote:
> 
>        Thought 3: therefore, the better course of action is to have
> functions or methods that dynamically compute what namespaces apply by
> looking at a node's ancestors.

This is probably the best, mostly because you want your 
namespace-enhanced DOM to be a superset of the regular DOM.

> 	  1) Get a dictionary mapping namespace prefixes to URIs, and
> vice versa; this would be done by walking up the tree looking at
> xmlns:* attributes.

I don't think that the programmer needs access to this dictionary. 
Internally you need it, but I don't think that the programmer should.

> This means that namespace-using applications won't have everything
> done for them; 

Why not?

> Python code might look vaguely like:
> 
> XSL_URI = "http://www.w3.org/..."
> uri = node.get_namespace_mapping()
> 
> # Next line assumes node is an Element tag
> nsp, name = divide_qualified_name( node.tagName )
> 
> if uri[nsp] == XSL_URI:

I think that this would be better:

uri, name = namespace_divide( node.tagName )

You can do the lookup internally, whether you use a dictionary or a walk 
up the tree is your business.

> would be useful as a test case?  It would also provide another demo
> application.  The transformation portion of XSL is one candidate, but
> I haven't read enough of the XSL draft to get an idea of how big the
> job would be.  Anyone know of something small?

How about an app that rewrote namespace prefixes to some canonical form to 
allow simple diff-ing. So maybe you have a configuration file like this:

<CONFIG>
<NAMESPACE URI="http://www.w3.org/XSL" PREFIX="xsl">
<NAMESPACE URI="http://www.w3.org/RDF" PREFIX="rdf">
<NAMESPACE URI="http://www.w3.org/XLink" PREFIX="xlink">
</CONFIG>

and you would feed in a document like this:

<DOC ...presume namespace declarations here...>
<x-style:element>...</x-style:element>
<metadata:description>...</metadata:description>
<xll:link>...</xll:link>
</DOC>

and would rewrite it (based on the elided namespace declarations and the 
configuration file) as:

<DOC ...presume namespace declarations here...>
<xsl:element>...</xsl:element>
<rdf:description>...</rdf:description>
<xll:link>...</xll:link>
</DOC>

This is useful for all of the usual reasons canoncalization is useful: to 
write simpler software that depends on the output instead of 
understanding the input. For instance if you were writing an RDF 
processor but were to lazy to handle the various requirements of 
namespaces you would pipe your data through the canoncalizer and do "dumb 
checks" like tagName=="rdf:description".

To be totally useful to programmers and not just as a demo app, it should 
actually transform one DOM into another (or, better, act as a lazy proxy).

I think that this app would use all features of the namespace draft.

 Paul Prescod