Project

Profile

Help

Issue with DOMImplementationImpl.hasFeature()

Added by Anonymous over 16 years ago

Legacy ID: #4711500 Legacy Poster: Alexandre Delarge (adelarge)

Hi, I'm running the following scenario using Java 5: 1) Handle an incoming SOAP request with Apache Axis v1.4 2) Query an external party web service (using Axis as well), and obtain some XML document as response 3) XSLT the obtained response using Saxon v8.7.3 4) Importing several nodes of the XSLT result into the SOAP response that is exposed by Axis 5) Return SOAP response to user The scenario runs fine, but the response sent to the user contains the imported Saxon nodes with an empty namespace. Here is an example of a node that is contained into the XSLT result produced by Saxon, and that I want to import: -- <ns1:TPA_Extensions xmlns:ns1="http://www.opentravel.org/OTA/2003/05"> <ns1:child1/> <ns1:child2/> [...] </ns1:TPA_Extensions> -- The imported version looks like that: -- <ns1:TPA_Extensions xmlns:ns1=""> <ns1:child1 xmlns:ns1=""/> <ns1:child2 xmlns:ns1=""/> [...] </ns1:TPA_Extensions> -- See the namespace loss during the import operation... By doing step by step debugging I could find the cause of that issue. The Java stack shows that the code executing the import job is "com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.importNode(Node source, boolean deep)". The relevant JDK sources excerpt for this method follows: -- [...] case ELEMENT_NODE: { Element newElement; boolean domLevel20 = source.getOwnerDocument().getImplementation().hasFeature("XML", "2.0"); // Create element according to namespace support/qualification. if(domLevel20 == false || source.getLocalName() == null) newElement = createElement(source.getNodeName()); else newElement = createElementNS(source.getNamespaceURI(), source.getNodeName()); [...] -- The source Node for this import operation is an instance of "net.sf.saxon.dom.ElementOverNodeInfo". The problem comes from the call to method 'getOwnerDocument().getImplementation().hasFeature("XML", "2.0")' onto that object, which always return false. Looking at Saxon source code, we see that 'getOwnerDocument().getImplementation()' will return an instance of "net.sf.saxon.dom.DOMImplementationImpl". The method "boolean hasFeature(String feature, String version)" in that class does always return false, making Xerces think it cannot handle XML namespaces. I've searched a bit for the definition of DOM features into the spec. but could not find something precise about it (see http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#DOMFeatures). Still, to have things working in my project I had to introduce a Saxon patch for class "net.sf.saxon.dom.DOMImplementationImpl" in my classpath. My questions: 1) Is it intentional for the implementation of that "net.sf.saxon.dom.DOMImplementationImpl" class to omit support of DOM features ? 2) If intentional, what is the reason ? And if not, is there any enhancement planned (same code appears in Saxon v9.0) ? Thanks for any help. Regards, Alexandre.


Replies (3)

Please register to reply

RE: Issue with DOMImplementationImpl.hasFeature() - Added by Anonymous over 16 years ago

Legacy ID: #4713551 Legacy Poster: Michael Kay (mhkay)

Thanks for doing the analysis on this. Achieving good interoperability between DOM implementations is notoriously difficult, but it looks as if I can fix this one by declaring the appropriate feature. I'll look into it in more detail next week.

RE: Issue with DOMImplementationImpl.hasFeatu - Added by Anonymous over 16 years ago

Legacy ID: #4713975 Legacy Poster: Alexandre Delarge (adelarge)

Thanks for your attention Michael, I'll be watching that forum thread for updates from you then :). Regards, Alexandre.

RE: Issue with DOMImplementationImpl.hasFeatu - Added by Anonymous over 16 years ago

Legacy ID: #4729189 Legacy Poster: Michael Kay (mhkay)

I've logged this as a bug at https://sourceforge.net/tracker/index.php?func=detail&amp;aid=1873863&amp;group_id=29872&amp;atid=397617 and a fix is in Subversion (though I haven't tested it in your particular scenario, of course)

    (1-3/3)

    Please register to reply