Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] [saxon] Bug (?) in Saxon/DOM/XOM interaction: Attributes instead ofnamespaces; strange element tree structure

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Christoph LANGE <ch.lange AT jacobs-university.de>
  • To: saxon-help AT lists.sourceforge.net
  • Cc: 'XOM' <xom-interest AT lists.ibiblio.org>, Sebastian Schaffert <sebastian.schaffert AT salzburgresearch.at>
  • Subject: Re: [XOM-interest] [saxon] Bug (?) in Saxon/DOM/XOM interaction: Attributes instead ofnamespaces; strange element tree structure
  • Date: Wed, 27 Feb 2008 12:41:09 +0100

Dear Michael, dear all,

thanks for your Saxon patch. I've tried it, but I think my test project was
not good enough. After fixing this stupid mistake, the test program ran
smoothly, whereas my real application failed with some completely different
error. A short summary of the following: I'm not able to reproduce the actual
bug, but the patched Saxon misbehaves in different ways. I'll first give a
new bug report and then reply to your mail below.

There is a difference about which I'm not sure what causes it, namely that in
my test program the DOM elements turn out to be of type
com.sun.org.apache.xerces.internal.dom.DeferredElementNSImpl, whereas I
remembered them being of some type net.sf.saxon.TinySomething when that but
occurred that I reported initially.

Now in my real application the patched Saxon fails with some completely
strange error, namely:

Error at element constructor <p> on line 114 of
jar:file:///var/lib/tomcat-6/webapps/SWiM/WEB-INF/lib/swim.jar!/at/srfg
/ikewiki/render/transform-mcd-html.xsl:
org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or
change an object
in a way which is incorrect with regard to namespaces.
ERROR [http-8080-1] (RenderingPipeline.java:1003) - error while applying
transformation (transform-html.xsl)
; SystemID:
jar:file:///var/lib/tomcat-6/webapps/SWiM/WEB-INF/lib/swim.jar!/at/srfg/ikewiki/render/transform-mcd-html.x
sl; Line#: 114; Column#: -1
net.sf.saxon.trans.DynamicError: org.w3c.dom.DOMException: NAMESPACE_ERR: An
attempt is made to create or change an object in a way which is incorrect
with regard to namespaces.
at net.sf.saxon.dom.DOMWriter.namespace(DOMWriter.java:125)
at net.sf.saxon.event.ProxyReceiver.namespace(ProxyReceiver.java:132)
at
net.sf.saxon.event.NamespaceReducer.namespace(NamespaceReducer.java:97)
at
net.sf.saxon.event.ComplexContentOutputter.startContent(ComplexContentOutputter.java:491)
at
net.sf.saxon.event.ComplexContentOutputter.startElement(ComplexContentOutputter.java:153)
at
net.sf.saxon.instruct.ElementCreator.processLeavingTail(ElementCreator.java:243)
at net.sf.saxon.instruct.Block.processLeavingTail(Block.java:353)
at net.sf.saxon.instruct.Instruction.process(Instruction.java:91)
at
net.sf.saxon.instruct.ElementCreator.processLeavingTail(ElementCreator.java:250)
at net.sf.saxon.instruct.Choose.processLeavingTail(Choose.java:338)
at net.sf.saxon.instruct.Template.applyLeavingTail(Template.java:99)
at
net.sf.saxon.instruct.ApplyTemplates.applyTemplates(ApplyTemplates.java:319)
at
net.sf.saxon.instruct.ApplyTemplates$ApplyTemplatesPackage.processLeavingTail(ApplyTemplates.java:488)
at
net.sf.saxon.instruct.ApplyTemplates.applyTemplates(ApplyTemplates.java:296)
at net.sf.saxon.instruct.ApplyTemplates.apply(ApplyTemplates.java:189)
at
net.sf.saxon.instruct.ApplyTemplates.processLeavingTail(ApplyTemplates.java:153)
at net.sf.saxon.instruct.Block.processLeavingTail(Block.java:353)
at net.sf.saxon.instruct.Instruction.process(Instruction.java:91)
at
net.sf.saxon.instruct.ElementCreator.processLeavingTail(ElementCreator.java:250)
at net.sf.saxon.instruct.Block.processLeavingTail(Block.java:353)
at net.sf.saxon.instruct.Instruction.process(Instruction.java:91)
at
net.sf.saxon.instruct.ElementCreator.processLeavingTail(ElementCreator.java:250)
at net.sf.saxon.instruct.Template.applyLeavingTail(Template.java:99)
at
net.sf.saxon.instruct.ApplyTemplates.applyTemplates(ApplyTemplates.java:319)
at
net.sf.saxon.instruct.ApplyTemplates$ApplyTemplatesPackage.processLeavingTail(ApplyTemplates.java:488)
at net.sf.saxon.Controller.transformDocument(Controller.java:1607)
at net.sf.saxon.Controller.transform(Controller.java:1426)

Of course, the XHTML namespace for the <p> element is properly declared. When
I remove the offending elements, the same "problem" is reported in other XSLT
files that used to work before. That's why I'm not able to test this in
further detail.

Could it be related to the fact that I used an outdated build.xml? After all,
I've never built Saxon myself (just downloaded the jar files), and now I
checked out the sources from SourceForge, applied your patch in the trunk (or
should I have used latest9.0?), and then there was no build.xml. The most
recent directory where I could find a build.xml was latest8.9. And, BTW, it
was somewhat hard to get it run, as I not only had to adapt a few paths but
also create some temporary directories, like build/temp/j/source, or is there
some ant target that creates them?

Now for my comments to your mail:

On Friday 22 February 2008 19:04:44 Michael Kay wrote:
> I think you're correct that when Saxon creates a DOM view of an underlying
> Saxon tree, the attribute node that represents the xmlns="xyz" declaration
> has a null namespace URI, whereas the DOM specifications strongly suggest
> that it should have a namespace URI of "http://www.w3.org/2000/xmlns/";. The
> reason for this rule escapes me completely, but it's what DOM says.

So I think Saxon follow the specification here, or is there any reason not to
do it?

> > The second bug occurs in
> > DOMConverter.convert(org.w3c.dom.Element element,
> > NodeFactory). It seems evident that the algorithm walks down
> > and up the given tree and quits when it again arrives at the
> > root node (i.e. element). In my application, this case never
> > occurs; instead, the algorithm arrives at a point where the
> > current node is null and runs into a NullPointerException.
>
> Without more information as to how the tree appears to be corrupt it's
> difficult to help.

Any ideas how to get at this information? Is there anything I could dump?

> A general point, though: is this really a sensible architecture?

No, it is not, but it was not my choice.

> Converting
> between three different representations of the data model seems to
> introduce a lot of complexity and overhead. One feels there must be a
> simpler way: in particular, can't you convert directly from the Saxon model
> to XOM, rather than going via DOM interfaces?

I would like to do so, but currently IkeWiki uses DOM, and the mmlkit
renderer
uses XOM. IkeWiki will eventually be switched to XOM, but not yet. And my job
with SWiM is to combine the two existing systems IkeWiki and mmlkit, so I'm
doomed to convert data.

On Friday 22 February 2008 19:10:17 you wrote:
> > This is again because the namespace node xmlns:m on the
> > m:apply element is misrepresented as an attribute.
>
> Let's be clear: DOM requires that namespaces are represented as attribute
> nodes. So I don't quite understand this conclusion. But I'll see if I can
> get your test code to run.

Hmmm, I was wrong here, thanks for clarifying. I was misled by thinking in
terms of e.g. XPath, where namespace nodes are different from attributes.

Best,

Christoph

--
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701




Archive powered by MHonArc 2.6.24.

Top of Page