[
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/ |
+----------------------------------+---------------------------------+
|
