You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Henry Zongaro <zo...@ca.ibm.com> on 2003/08/28 11:54:40 UTC
XSLT and XPath 2.0 development
Hello,
Last year, several Xalan-J developers worked on a prototype
implementation of the XSLT/XPath 2.0 draft recommendations based on the
Xalan-Java Interpretive processor. The work was carried out on the xslt20
branch of the xml-xalan module. Some preliminary work also began on 2.0
support for XSLTC. As the developers who worked on the xslt20 branch
began to focus on other projects, nobody was available to carry on that
work, so it has languished for some time. The work was based on older
draft revisions of the recommendations; that, coupled with bug fixes and
performance enhancements on the main branch, has caused the code on the
xslt20 branch to become badly out of date.
Over the past year, Xalan-J developers have placed a lot of emphasis on
improving XSLTC's level of conformance with the XSLT/XPath 1.0
recommendations. More recently, there's been a number of significant
performance improvements to XSLTC. The way things currently stand, it
looks like it would be better for future development of XSLT/XPath 2.0 to
resume on the XSLTC code-base. XSLTC has much better performance
characteristics than Xalan-J Interpretive, and it would be much easier to
add missing functionality to XSLTC than it would be either to continue
supporting and developing two very different processors in parallel,
thereby dividing scarce resources, or to develop only Xalan-J Interpretive
and try to catch up to XSLTC in terms of performance.
If there's significant continued interest in Xalan-J Interpretive, or if
there are things that could be done with the interpretive processor that
just can't be done with the compiling processor, we could look at reviving
XSLT/XPath 2.0 support in Xalan-J Interpretive. But in the short-term and
medium-term, I think that we're more likely to see this work succeed by
focusing on XSLTC.
Some groundwork for XSLT/XPath 2.0 support in XSLTC has already
begun. In particular:
. Morris Kwan has been adapting XSLTC to use the JJTree-generated XPath
2.0 parser, using the AST code contributed by Lionel Villard, that was used on the xslt20 branch - the grammar from which that parser
is derived is generated from the same source as the grammar that appears
in the XPath 2.0 draft recommendation. Scott Boag is bringing the grammar
up to date with the current version in the latest XPath 2.0 draft.
. Christine Li has begun prototyping support for XPath 2.0 Functions and
Operators.
. Brian Minchau has begun to look at requirements for serialization in
XSLT 2.0.
. Joseph Kesselman and Myriam Midy have been working to adapt the Extended
Data Model (XDM) support from the xslt20 branch to XSLTC. That's not
really something that enables XSLT/XPath 2.0 support, but rather opens up
Xalan-J to accepting input from a wide array of sources.
Very shortly, we'd like to contribute those first pieces of code to
Apache, and publish a prelimary development plan to get us on the path to
XSLT/XPath 2.0 support. There should be plenty of work for all interested
parties!
In the meanwhile, I'd like to propose that we rename the existing
xslt20 branch to xslt20-interp, and that we create a new xslt20-compiled
branch on which we can develop XSLTC. It will probably take a fair amount
of time before the new development can replace the existing processors, so
I'd propose that we continue to maintain and develop the existing
XSLT/XPath 1.0 processors on the MAIN branch of xml-xalan. At some point
in the future, the community can decide whether to move the new XSLT 2.0
processor to the MAIN branch.
Questions, comments, endorsements and objections would be welcomed!
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro Xalan development
IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com
Re: XSLT and XPath 2.0 development
Posted by Udi <ud...@conformative.com>.
regarding this (old) mail, could you please give details of the current
plans (if any) for 2.0 support in Xalan-C ?
thanx, -udi-
----- Original Message -----
From: "Henry Zongaro" <zo...@ca.ibm.com>
To: <xa...@xml.apache.org>
Sent: Thursday, August 28, 2003 4:54 AM
Subject: XSLT and XPath 2.0 development
> Hello,
>
> Last year, several Xalan-J developers worked on a prototype
> implementation of the XSLT/XPath 2.0 draft recommendations based on the
> Xalan-Java Interpretive processor. The work was carried out on the xslt20
> branch of the xml-xalan module. Some preliminary work also began on 2.0
> support for XSLTC. As the developers who worked on the xslt20 branch
> began to focus on other projects, nobody was available to carry on that
> work, so it has languished for some time. The work was based on older
> draft revisions of the recommendations; that, coupled with bug fixes and
> performance enhancements on the main branch, has caused the code on the
> xslt20 branch to become badly out of date.
>
> Over the past year, Xalan-J developers have placed a lot of emphasis
on
> improving XSLTC's level of conformance with the XSLT/XPath 1.0
> recommendations. More recently, there's been a number of significant
> performance improvements to XSLTC. The way things currently stand, it
> looks like it would be better for future development of XSLT/XPath 2.0 to
> resume on the XSLTC code-base. XSLTC has much better performance
> characteristics than Xalan-J Interpretive, and it would be much easier to
> add missing functionality to XSLTC than it would be either to continue
> supporting and developing two very different processors in parallel,
> thereby dividing scarce resources, or to develop only Xalan-J Interpretive
> and try to catch up to XSLTC in terms of performance.
>
> If there's significant continued interest in Xalan-J Interpretive, or
if
> there are things that could be done with the interpretive processor that
> just can't be done with the compiling processor, we could look at reviving
> XSLT/XPath 2.0 support in Xalan-J Interpretive. But in the short-term and
> medium-term, I think that we're more likely to see this work succeed by
> focusing on XSLTC.
>
> Some groundwork for XSLT/XPath 2.0 support in XSLTC has already
> begun. In particular:
>
> . Morris Kwan has been adapting XSLTC to use the JJTree-generated XPath
> 2.0 parser, using the AST code contributed by Lionel Villard, that was
used on the xslt20 branch - the grammar from which that parser
> is derived is generated from the same source as the grammar that appears
> in the XPath 2.0 draft recommendation. Scott Boag is bringing the grammar
> up to date with the current version in the latest XPath 2.0 draft.
>
> . Christine Li has begun prototyping support for XPath 2.0 Functions and
> Operators.
>
> . Brian Minchau has begun to look at requirements for serialization in
> XSLT 2.0.
>
> . Joseph Kesselman and Myriam Midy have been working to adapt the Extended
> Data Model (XDM) support from the xslt20 branch to XSLTC. That's not
> really something that enables XSLT/XPath 2.0 support, but rather opens up
> Xalan-J to accepting input from a wide array of sources.
>
> Very shortly, we'd like to contribute those first pieces of code to
> Apache, and publish a prelimary development plan to get us on the path to
> XSLT/XPath 2.0 support. There should be plenty of work for all interested
> parties!
>
> In the meanwhile, I'd like to propose that we rename the existing
> xslt20 branch to xslt20-interp, and that we create a new xslt20-compiled
> branch on which we can develop XSLTC. It will probably take a fair amount
> of time before the new development can replace the existing processors, so
> I'd propose that we continue to maintain and develop the existing
> XSLT/XPath 1.0 processors on the MAIN branch of xml-xalan. At some point
> in the future, the community can decide whether to move the new XSLT 2.0
> processor to the MAIN branch.
>
> Questions, comments, endorsements and objections would be welcomed!
>
> Thanks,
>
> Henry
> ------------------------------------------------------------------
> Henry Zongaro Xalan development
> IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
> mailto:zongaro@ca.ibm.com
RE: XSLT and XPath 2.0 development
Posted by sc...@us.ibm.com.
Rick, your input is very helpful and valid. Let me think on it a while.
-scott
RE: XSLT and XPath 2.0 development
Posted by Rick Bullotta <ri...@lighthammer.com>.
The "dynamism" that is needed to build certain kinds of processing logic
into XSLT almost demands some type of on-the-fly compilation. I can see
two ways to achieve the same "end game":
1) Built into the XSL processor itself
2) Built external to the XSL processor by manipulation of the
structure/content of the XSL document itself, and the "mutated" XSL is
then processed normally by the XSL processor
On an application basis, #2 is certainly viable, however, it does create
a "non-standard" or application-specific approach to the problem. One
thought would be a hybrid approach that provided some type of
entity/parameter replacement above and beyond standard XSL parameters.
The XSL processor could generically deal with this entity/parameter
parsing/replacement, and presence of such things would flag the XSL
processor that a recompilation was required.
I think we'll lean towards massaging the XSL being fed into the XSLTC
engine, though I'll admit we're still unclear as to some of the "under
the hood" dynamics of how to optimize this (e.g. caching and re-using
the compiled state, etc.) and the implications of "one-off" XSLTC
compilations versus interpretive processing (e.g. is the compile step
more costly in terms of performance than interpretive execution?).
In any case, the need to dynamic XSL is indeed a very real one. I
welcome your thoughts and ideas on how to meet the challenge!
Rick Bullotta
CTO
Lighthammer Software (http://www.lighthammer.com
<http://www.lighthammer.com/> )
-----Original Message-----
From: scott_boag@us.ibm.com [mailto:scott_boag@us.ibm.com]
Sent: Thursday, August 28, 2003 6:30 PM
To: xalan-dev@xml.apache.org
Subject: RE: XSLT and XPath 2.0 development
You can still implement dynamic evaluation in a compiled environment...
it just means a) the compiler needs to be available as part of the
runtime, and b) we would need to set these things up to compile
fragments.
But, I guess what you really loose is that I've seen some user
extensions that mutate the stylesheet at runtime. This becomes a harder
proposition. My knee-jerk is that the world could live without this,
though I'm not so sure when I think of some editing environments.
Sigh.
-scott
"Rick Bullotta" <ri...@lighthammer.com> wrote on 08/28/2003
10:45:20 AM:
> A few thoughts:
>
> Our application work requires considerable usage of extension
functions,
> notably some of the Xalan/EXSLT dynamic functions (evaluate, min, and
> max), which appear to be "structurally unsupportable" in XSLTC. As
> such, we would certainly be interested in seeing Xpath 2.0 support on
> Xalan-J interpretive. As a use case, example, suppose an XML document
> contains rows and columns of data in a format such as:
>
......
RE: XSLT and XPath 2.0 development
Posted by sc...@us.ibm.com.
You can still implement dynamic evaluation in a compiled environment... it
just means a) the compiler needs to be available as part of the runtime,
and b) we would need to set these things up to compile fragments.
But, I guess what you really loose is that I've seen some user extensions
that mutate the stylesheet at runtime. This becomes a harder proposition.
My knee-jerk is that the world could live without this, though I'm not so
sure when I think of some editing environments.
Sigh.
-scott
"Rick Bullotta" <ri...@lighthammer.com> wrote on 08/28/2003
10:45:20 AM:
> A few thoughts:
>
> Our application work requires considerable usage of extension functions,
> notably some of the Xalan/EXSLT dynamic functions (evaluate, min, and
> max), which appear to be "structurally unsupportable" in XSLTC. As
> such, we would certainly be interested in seeing Xpath 2.0 support on
> Xalan-J interpretive. As a use case, example, suppose an XML document
> contains rows and columns of data in a format such as:
>
> <ROWS>
> <ROW>
> <COL1>FOO</COL1>
> <COL2>100</COL2>
> <COL3>0.5</COL3>
> </ROW>
> <ROW>
> <COL1>GOO</COL1>
> <COL2>200</COL2>
> <COL3>0.75</COL3>
> </ROW>
> </ROWS>
>
> ...and we allow a user to provide an "ad-hoc expression", e.g.
> "sin(COL2) * 0.6 + COL3 / 45", and we use XSL to transform this
> recordset into something that looks like:
>
> <ROWS>
> <ROW>
> <COL1>FOO</COL1>
> <COL2>100</COL2>
> <COL3>0.5</COL3>
> <CALCULATED>0.12455</CALCULATED>
> </ROW>
> <ROW>
> <COL1>GOO</COL1>
> <COL2>200</COL2>
> <COL3>0.75</COL3>
> <CALCULATED>0.00378</CALCULATED></ROW>
> </ROWS>
>
> ...in which case we really need to leverage things like the evaluate
> function.
>
> Another example is an XSL stylesheet which performs basic
> grouptotal/grandtotal functions on a dataset, but the sort and subtotal
> rules are dynamic. Once again, we have to resort to using the evaluate
> extension function to meet our application needs.
>
> That would be the only showstopper for us, as far as I can see.
>
> Best regards,
>
> Rick Bullotta
> CTO
> Lighthammer Software (http://www.lighthammer.com)
>
>
>
> -----Original Message-----
> From: Henry Zongaro [mailto:zongaro@ca.ibm.com]
> Sent: Thursday, August 28, 2003 5:55 AM
> To: xalan-dev@xml.apache.org
> Subject: XSLT and XPath 2.0 development
>
>
> Questions, comments, endorsements and objections would be welcomed!
>
> Thanks,
>
> Henry
> ------------------------------------------------------------------
> Henry Zongaro Xalan development
> IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
> mailto:zongaro@ca.ibm.com
>
Re: Xerces / Xalan on PPC
Posted by Udi <ud...@conformative.com>.
Berin,
thanx for the info. i'll follow up on it.
-udi-
----- Original Message -----
From: "Berin Lautenbach" <be...@ozemail.com.au>
To: <xa...@xml.apache.org>
Sent: Saturday, October 11, 2003 3:27 AM
Subject: Re: Xerces / Xalan on PPC
> Udi,
>
> Haven't personally tried. However I know the Debian auto-builders
> create a PPC version of the i386 source package that gets uploaded.
> There are some bugs in the Debian system at the moment around Xerces on
> PPC, but they are still there more because of problems getting updates
> through to testing.
>
> However I know there have been PPC versions of Xalan auto-building and
> working correctly under Debian in the past.
>
> If you're interested - you can see the build logs for various machine
> types at:
>
> http://buildd.debian.org/build.php?pkg=xalan
>
> Cheers,
> Berin
>
>
> Udi wrote:
> > Folks
> > Could anyone point me to sources of
> > information/advise/general-impressions of building Xalan on PPC/Linux ?
> > Thanx, -udi-
> >
> >
>
Re: Xerces / Xalan on PPC
Posted by Berin Lautenbach <be...@ozemail.com.au>.
Udi,
Haven't personally tried. However I know the Debian auto-builders
create a PPC version of the i386 source package that gets uploaded.
There are some bugs in the Debian system at the moment around Xerces on
PPC, but they are still there more because of problems getting updates
through to testing.
However I know there have been PPC versions of Xalan auto-building and
working correctly under Debian in the past.
If you're interested - you can see the build logs for various machine
types at:
http://buildd.debian.org/build.php?pkg=xalan
Cheers,
Berin
Udi wrote:
> Folks
> Could anyone point me to sources of
> information/advise/general-impressions of building Xalan on PPC/Linux ?
> Thanx, -udi-
>
>
Xerces / Xalan on PPC
Posted by Udi <ud...@conformative.com>.
Folks
Could anyone point me to sources of
information/advise/general-impressions of building Xalan on PPC/Linux ?
Thanx, -udi-
RE: XSLT and XPath 2.0 development
Posted by Rick Bullotta <ri...@lighthammer.com>.
A few thoughts:
Our application work requires considerable usage of extension functions,
notably some of the Xalan/EXSLT dynamic functions (evaluate, min, and
max), which appear to be "structurally unsupportable" in XSLTC. As
such, we would certainly be interested in seeing Xpath 2.0 support on
Xalan-J interpretive. As a use case, example, suppose an XML document
contains rows and columns of data in a format such as:
<ROWS>
<ROW>
<COL1>FOO</COL1>
<COL2>100</COL2>
<COL3>0.5</COL3>
</ROW>
<ROW>
<COL1>GOO</COL1>
<COL2>200</COL2>
<COL3>0.75</COL3>
</ROW>
</ROWS>
...and we allow a user to provide an "ad-hoc expression", e.g.
"sin(COL2) * 0.6 + COL3 / 45", and we use XSL to transform this
recordset into something that looks like:
<ROWS>
<ROW>
<COL1>FOO</COL1>
<COL2>100</COL2>
<COL3>0.5</COL3>
<CALCULATED>0.12455</CALCULATED>
</ROW>
<ROW>
<COL1>GOO</COL1>
<COL2>200</COL2>
<COL3>0.75</COL3>
<CALCULATED>0.00378</CALCULATED></ROW>
</ROWS>
...in which case we really need to leverage things like the evaluate
function.
Another example is an XSL stylesheet which performs basic
grouptotal/grandtotal functions on a dataset, but the sort and subtotal
rules are dynamic. Once again, we have to resort to using the evaluate
extension function to meet our application needs.
That would be the only showstopper for us, as far as I can see.
Best regards,
Rick Bullotta
CTO
Lighthammer Software (http://www.lighthammer.com)
-----Original Message-----
From: Henry Zongaro [mailto:zongaro@ca.ibm.com]
Sent: Thursday, August 28, 2003 5:55 AM
To: xalan-dev@xml.apache.org
Subject: XSLT and XPath 2.0 development
Questions, comments, endorsements and objections would be welcomed!
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro Xalan development
IBM SWS Toronto Lab T/L 969-6044; Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com
Re: XSLT and XPath 2.0 development
Posted by sc...@us.ibm.com.
One way to proceed might be to look at the interpretive version as a
visitor of the same AST that the compiler uses.
The goal really is to collapse the amount of code that has to be
maintained (and developed).
-scott
Lionel Villard <vi...@us.ibm.com> wrote on 08/28/2003 09:45:46 AM:
>
> >If there's significant continued interest in Xalan-J Interpretive, or
if
> >there are things that could be done with the interpretive processor
that
> >just can't be done with the compiling processor, we could look at
reviving
> >XSLT/XPath 2.0 support in Xalan-J Interpretive. But in the short-term
and
> >medium-term, I think that we're more likely to see this work succeed by
> >focusing on XSLTC.
>
>
> In my opinion, the main interest of the Xalan-J Interpretive is its
> uses within authoring tools, even though there are some features
> that are missing to be really usable in such environnement (no real
> AST for XSLT and XPath, no incrementality). In order to use XSLTC in
> authoring tools, we need to provide additionnal features, like
> incremental compilation and incremental execution, which I think are
> not so trivial to implement. I think it's easier to make Xalan-J
> interpretive simpler, to be less agressive in term of optimizations,
> to have a sort of "lightweight" implementation of XSLT targeting
> authoring tools only (or more generally tools that need to
> manipulate XSLT stylesheet without caring to much about execution
> performance), and to start really to think about incrementality
> (updating the target document when the *stylesheet* is modified,
> which is relatively easy to do, and not when the source document is
> modified, which is hard in the general case).
>
> Lionel Villard
> IBM Research
Re: XSLT and XPath 2.0 development
Posted by Lionel Villard <vi...@us.ibm.com>.
>If there's significant continued interest in Xalan-J Interpretive, or if
>there are things that could be done with the interpretive processor that
>just can't be done with the compiling processor, we could look at
reviving
>XSLT/XPath 2.0 support in Xalan-J Interpretive. But in the short-term
and
>medium-term, I think that we're more likely to see this work succeed by
>focusing on XSLTC.
In my opinion, the main interest of the Xalan-J Interpretive is its uses
within authoring tools, even though there are some features that are
missing to be really usable in such environnement (no real AST for XSLT
and XPath, no incrementality). In order to use XSLTC in authoring tools,
we need to provide additionnal features, like incremental compilation and
incremental execution, which I think are not so trivial to implement. I
think it's easier to make Xalan-J interpretive simpler, to be less
agressive in term of optimizations, to have a sort of "lightweight"
implementation of XSLT targeting authoring tools only (or more generally
tools that need to manipulate XSLT stylesheet without caring to much about
execution performance), and to start really to think about incrementality
(updating the target document when the *stylesheet* is modified, which is
relatively easy to do, and not when the source document is modified, which
is hard in the general case).
Lionel Villard
IBM Research