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 namespace declarati

[ Lists Home | Date Index | Thread Index ]


I tried Saxon's identity transform on your document:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"
<svg xmlns="http://www.w3.org/2000/svg"/>

(actually you had a spurious ";" after "svg10.dtd")

and got the following output:

<svg xmlns="http://www.w3.org/2000/svg"; contentStyleType="text/css"
contentScriptType="text/ecmascript" preserveAspectRatio="xMidYMid meet"
version="1.0" zoomAndPan="magnify"></svg>

This was using the Crimson DOM as a DOMSource input, and a SAXSource output
which did trivial serialization of the SAX events. It's different from your
reported result in that (a) it got the namespace right, and (b) it expanded
default attribute values from the DTD. These are both behaviors you would
expect if the transformation preserves the XPath data model.

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",
       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.

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.

Mike Kay


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

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