XOM API for Processing XML with Java

[Christoph LANGE <ch.lange AT jacobs-university.de>]

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