The need for a liaison implementation for Xalan to use a non-Xerc es XML parser?

[Brian Young <Brian.Young@xxxxxxx>]

Hello,

This is something that I've been scratching my head about for weeks, and I was hoping for some enlightenment from you folks:

When using Xalan v1.1.d01, why must I implement a liaison class in order to work with any XML parser other than Xerces v1.1.1 (or v1.1.2)?  The need for a liaison is expressed in the Release Notes for Xalan: "You can use Xalan with other XML parsers, but it is up to you to implement liaisons to those parsers."

I'd love to use Sun's JAXP reference implementation, as another product that we ship with is using that.  Our other product doesn't do XSLT, though, so they never bumped into this issue.

I admit that I'm an extreme novice when it comes to parser/processor interactions as well as DOM and SAX.  I've been more concerned with producing good XML, authoring XSLT, and just instantiating the processor and feeding it those two input files and giving it an output file to stream to.  I thought switching out the underlying XML parser would be easy.  Here is my thinking...

Since Xalan v1.1.d01 ships with Xerces v1.1.2, which supports JAXP, then it stands to reason that Xalan v1.1.d01 would use the API defined by JAXP to interact with the XML parser.  That may be my first mistaken assumption.  Section 7.2 of the JAXP v1.0 specification says "In a future version of the specification, we would like to provide a plugability API to allow an application programmer to provide an XML document and an XSLT document to a wrapped XSLT processor and obtain a transformed result."  Hmmm, I thought that was kind of what JAXP did already?  So, assuming that my assumption is correct, and that JAXP is a standard API that defines an XSL processors interactions with an XML parser, why could I *not* switch Xerces v1.1.2 out for the JAXP reference implementation?

I'm wondering if this is one of those bleeding edge areas where the intent is there but reality doesn't live up to the specifications.  This is hinted at in the JavaDoc for the XMLParserLiaison interface: "[The interface] is needed in order to support features like included files, and to cover for deficiencies in the DOM."

Is this a case where the DOM served up by the JAXP reference implementation is just not up to snuff with that expected by Xalan?  I suspect more and more that this is the case, particularly given the statement at the main page for Xalan: "By default, it uses the Xerces XML parser, but it can interface to any XML parser that conforms to the DOM level 2 or SAX level 1 specification."  Meanwhile, the JAXP reference implementation states: "This release offers 100% conformance to the XML 1.0 Specification, SAX 1.0, DOM Level 1 Core and XML namespaces."

So, this data dump (thanks for bearing with me if you have gotten this far) begs a few questions:
1)  Is my assumption that JAXP is meant to be the standard API between an XML parser and an XSL processor correct?  How does JAXP v1.0 fail to meet this goal?
2)  Is the failure of the JAXP reference implementation to work with Xalan (without coding a liaison class) due not to the JAXP interface but rather to differences in the DOM (level 1 vs. 2)?
3)  Is the difference in the DOM the sole reason why a liaison must be used?  In other words, were the next version of the JAXP reference implementation to support level 2 *or* I decided to use SAX (since both support 1.0) would it then "just work"?
4)  Are there any XSL processors out there that "just work" with the JAXP reference implementation?  I know that there is a Sun XSLT compiler, and I *imagine* it uses JAXP reference, but it is not production yet.

Insight is really appreciated.  I'm learning, but not fast enough (and don't have the industry-wide view I need) to grasp this stuff as quick as I'd like to.

Thanks,
   Brian Young


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list