Re: [xsl] XPath over DOM

Subject: Re: [xsl] XPath over DOM
From: Alexey Gokhberg <alexei@xxxxxxxxxx>
Date: Thu, 15 Feb 2001 12:47:10 +0100
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


Current Thread