Re: XPath over DOM
Uche Ogbuji wrote: > > > Are there any Java-based XSLT or XPath implementations (at least partial > > functionality) that can traverse over existent DOM object, as opposed to > > creating their own in-memory structure? I need to be able to provide my own > > Document object built by my own parser, not just DOM APIs over internal > > processor structure (as Saxon implementation). > > Why would any Java XSLT processor have a problem working with another's DOM > nodes? > > Could it be that even for mighty Java, interoperability is all illusory? > Hello I guess (I may be wrong), that in this particular case we deal with another interoperability problem. This problem is caused by the nature of W3C recommendations, but is not related to Java. The issue is, at my opinion, that DOM (levels 1 and 2) and XSLT/XPath (and XML Infoset ??) are using different document models. To be specific, namespaces are handled differently. In XSLT/XPath, every element node must have attached the distinct list of namespace nodes for all namespaces on the scope of that node. Any particular namespace declaration must be replicated as a unique namespace node on each descendant element of the element which originally declared that namespace. In DOM, there is no thing like a namespace node at all; namespace declarations appear as normal attribute nodes only once, on the node representing an element which originally declared that namespace. There also some minor differences (in XSLT/XPath the parent of an attribute is its owner element; in DOM it is always null). I do not claim that these two document models are incompatible. It is possible to implement mapping between these two models; one can create an API on the top of DOM, which implements the document model required by XSLT/XPath. I guess (again, I may be wrong) that many XSLT vendors find implementation of such mapping impractical. Performance can be one reason. In particular, the specially designed representation of the source document can become a key factor in achieving a good performance, especially for processing large documents; so many XSLT processors may strongly rely on such (internal, proprietary) representation. It may be technically difficult (though not impopssible) to write a single piece of code (not necessarily in Java) which can work with both proprietary data representation and with data represented using DOM. Anyway, the fact that various branches of W3C recommendations are based on conceptually different document models is certainly alarming. It is very bad for interoperability; even worse, it is probably too late now to change anything. More problems may arise, once W3C will start to issue recommendationss which rely on both DOM and XSLT/XPath specifications. Kind regards, Alexey Gokhberg Unicorn Enterprises XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format