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] JAXP's ID Transform failing to include namespacedeclaratio

[ Lists Home | Date Index | Thread Index ]

At 5:47 PM +0000 1/7/02, Michael Kay wrote:

>I think the problem with the missing namespace is that your Java code to
>create the DOM is producing a DOM that isn't equivalent to the one created
>by parsing the above document. The code you gave is this:
>        // Create the document
>        DocumentType svgDOCTYPE = impl.createDocumentType(
>         "svg", "-//W3C//DTD SVG 1.0//EN",
>         "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd";;
>        );
>        Document doc = impl.createDocument(
>         "http://www.w3.org/2000/svg";;, "svg", svgDOCTYPE);
>The resulting DOM contains no namespace declaration attribute, whereas the
>one created by parsing the source does have such an attribute. Saxon
>actually supplies the missing declaration if the element name contains a
>":", but doesn't do so otherwise (this was probably a misguided attempt to
>work both with level 1 and level 2 DOM implementations). I'll fix this.

Absolutely, that is the problem. I have no doubt of this. However, 
the argument is about who's supposed to fix it. My claim is that 
JAXP's ID transform (and for that matter its XSLT transforms, or any 
XSLT transform that's starting with a DOM Document instead of a text 
file) should notice that there are no xmlns attributes corresponding 
to the namespaces in use and behave accordingly. If I understand you, 
you're saying you already do that for prefixed elements, and are 
going to add that behavior for unprefixed elements in the default 
namespace. If so, that should fix everything. :-)

Another way of thinking about it: when making the transition from the 
DOM data model to the XPath data model, XPath namespace nodes must be 
accumulated not just from DOM Attr objects but also from the 
namespace URIs and prefixes present on DOM elements and attributes.

>Also the DOM created programmatically doesn't contain attribute nodes
>corresponding to the default values of attributes defined in the DTD -
>another thing that is liable to confuse applications. Generally, this all
>exposes one of the big problems with the DOM - it is trivially easy to
>create DOM instances programatically that could never result from parsing a
>well-formed document, which all makes it rather hard work to write
>applications that are prepared to accept an arbitrary DOM as input.

I agree this is a major flaw of DOM. In fact, it's even possible to 
produce DOM documents that not only could not have been parsed from 
an XML document. It's even possible to create DOM documents that 
cannot possibly be serialized to a well-formed XML document. 
Unfortunately, we have to live with it. :-(

| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|              http://www.ibiblio.org/xml/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.ibiblio.org/xml/     |


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

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