Lionel,
in merging the serializer used by Xalan-J interpretive and XSLTC many such
dependancies have already been removed. The dependancies came up in a
number of areas including error messages and tracing for tools.
The new package for the serializer is org.apache.xml.serializer and it
shouldn't have dependancies on XSLTC or on Xalan-J interpretive. Please
correct me if I'm wrong on that because I worked hard on cutting
dependencies and if there are any left then I'd like to get rid of them.
The only things left in org.apache.xalan.serializer are marked as
depricated. There are still some dependancies on org.apache.xml.utils
which I presume are OK. (?)
This cutting of dependancies wasn't done so much for XSLT 2.0, but to make
sure that XSLTC didn't get a dependancy on Xalan-J interpretive because it
was using the new serializer.
Brian Minchau
XSLT Development, IBM Toronto
e-mail: [EMAIL PROTECTED]
"The voices in your head are so loud that even I can hear them."
----- Forwarded by Brian Minchau/Toronto/IBM on 08/03/2003 01:59 PM -----
Lionel
Villard/Watson/IB To: [EMAIL PROTECTED]
[EMAIL PROTECTED] cc:
Subject: XSLT/XQuery serialization:
toward a separate implementation
08/01/2003 11:03
AM
Please respond to
xalan-dev
Hi all,
with the forthcoming W3C recommendation for XSLT 2.0 and XQuery 1.0
serialization, it'd be great whether we can provide a separate
implementation from the xslt processing. I think it should not be so hard
and long to cut dependencies with Xalan in the org.apache.xalan.serialize
package. What do you think? Should we also provide an other package name,
like org.apache.xquery.serialization (xquery because the serialization may
belong to the data model of xpath/xquery and xslt relies on this datamodel)
?
Thanks!
Lionel Villard
IBM Research
