Does that leave an open question then as to whether or not
the overall responsibility for XSLT 2 conformance relies with
the XSLT 2 processor even though the bug is attributable to
the XML parser?
Yes, it's an open question, but it's an engineering/contractual question,
not really a spec conformance question.
As far as Saxon is concerned, the product is designed to enable you to
choose your own XML parser, and if you choose a buggy one, then the official
response is that you made a bad choice. One thing I learned from the
experience of bundling AElfred in the early days is that if you bundle a
software component, you take responsibility for supporting it; if you don't
bundle it, then the integration responsibility rests with the user.
In practical terms, writing an XSLT processor that's resilient to arbitrary
bugs in the XML parser is not a practical proposition. And the bugs in the
Sun version of Xerces are pretty arbitrary...
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--