Xalan3 XSLT 2.0 XPath 2.0 support?

[Henry Zongaro]

Hi, Johannes.

I'm cross-posting to both mailing lists to make sure we have broad
coverage for this discussion. Everyone, please follow up on
xalan-j-users.

Will future releases of Xalan-J definitively support XSLT 2.0 and XPath
2.0?
I searched the user and dev mailing lists and found only 4 year old
postings that say that there will be XSLT 2.0 implementations in future
Xalan-J Releases. Furthermore I found the xslt20/ and xslt20-compiled/
branches in the SVN repositories, but 4 years passed since the last
checkin, too.

Speaking as a committer on the Apache Xalan project, I'd certainly be
interested in seeing an XSLT 2.0 implementation take shape here. I'd like
to find out how much interest there is from others in seeing an open
source XSLT 2.0 implementation from the ASF. If you're interested in such
an implementation (as a user), please respond and let us know which
features you're most interested in. And conversely, I would also like to
hear from any users who are satisfied with an XSLT 1.0 processor, and not
much interested in migrating to XSLT 2.0.

Feel free to respond either on the mailing list or to me directly, in
private. I'll summarize the results of this informal polling in a week or
so.

In another mail-archive (not in a apache related) I found a posting that
claimed that a apache programmer has said that there won't come any
implementations for the new specifications, because the management does
not agree with them.

For the benefit of the list, I thought I should mention that you told me
in a private e-mail that you later realized it was a developer on a
different XSLT processor (not an Apache Xalan developer) who said they had
no interest in XSLT 2.0.

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro XSLT Processors Development
IBM SWS Toronto Lab T/L 969-6044; Phone [phone]
mailto:***@ca.ibm.com

[Jarle B. Hjortland]

We really would like to see the xpath functions in xslt 2.0. We have
considered moving to Oracle XML to get XSLT 2.0 support.

I would even be willing to put in some Company/Spare time to implement some
of these functions.



Jarle
--
--------- CORENA NORGE AS ---------
Jarle B. Hjortland - Software Engineer
Chief Architect Products
Tel: [phone], Mob: [phone]
Address: Dyrmyrgata 35, N-3611 Kongsberg
<http://www.corena.com> www.corena.com





From: Henry Zongaro [mailto:***@ca.ibm.com]
Sent: 26. juli 2007 12:06
To: xalan-***@xml.apache.org; xalan-j-***@xml.apache.org;
***@cs.uni-dortmund.de
Subject: Re: Xalan3 XSLT 2.0 XPath 2.0 support?




Hi, Johannes.

I'm cross-posting to both mailing lists to make sure we have broad coverage
for this discussion. Everyone, please follow up on xalan-j-users.

Will future releases of Xalan-J definitively support XSLT 2.0 and XPath
2.0?
I searched the user and dev mailing lists and found only 4 year old
postings that say that there will be XSLT 2.0 implementations in future
Xalan-J Releases. Furthermore I found the xslt20/ and xslt20-compiled/
branches in the SVN repositories, but 4 years passed since the last
checkin, too.

Speaking as a committer on the Apache Xalan project, I'd certainly be
interested in seeing an XSLT 2.0 implementation take shape here. I'd like
to find out how much interest there is from others in seeing an open source
XSLT 2.0 implementation from the ASF. If you're interested in such an
implementation (as a user), please respond and let us know which features
you're most interested in. And conversely, I would also like to hear from
any users who are satisfied with an XSLT 1.0 processor, and not much
interested in migrating to XSLT 2.0.

Feel free to respond either on the mailing list or to me directly, in
private. I'll summarize the results of this informal polling in a week or
so.

In another mail-archive (not in a apache related) I found a posting that
claimed that a apache programmer has said that there won't come any
implementations for the new specifications, because the management does
not agree with them.

For the benefit of the list, I thought I should mention that you told me in
a private e-mail that you later realized it was a developer on a different
XSLT processor (not an Apache Xalan developer) who said they had no interest
in XSLT 2.0.

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro XSLT Processors Development
IBM SWS Toronto Lab T/L 969-6044; Phone [phone]
mailto:***@ca.ibm.com

[Johannes Neubauer]

Hi Henry,

Post by Henry Zongaro
Speaking as a committer on the Apache Xalan project, I'd certainly be
interested in seeing an XSLT 2.0 implementation take shape here. I'd
like to find out how much interest there is from others in seeing an
open source XSLT 2.0 implementation from the ASF. If you're
interested in such an implementation (as a user), please respond and
let us know which features you're most interested in. And conversely,
I would also like to hear from any users who are satisfied with an
XSLT 1.0 processor, and not much interested in migrating to XSLT 2.0.

Ok, I will make a start here, though it is clear that I'm interested in
an implementation, of course.

Microsoft has pronounced to implement an XSLT 2.0 processor a few days
after the specification became recommendation status in january. I think
Xalan, as one of the main XSLT 1.0 implementations, should support an
open source XSLT 2.0 processor as an OS alternative to the saxon-sa and
microsoft implementations.

I think Xalan has the great advantage to meet the two standards JAXP and
XSLT. This tradition should be carried on to XSLT 2.0.

Many might say, that XSLT 1.0 with EXSLT and vendor specific functions
almost does the job of XSLT 2.0, but the new specification standardizes
these functions and supports schema validation of result elements and
many more. Especially XPath 2.0 is a real step forward. The
<xsl:for-each-group/> and <xsl:analyze-string/> statements are great,
two. The support for regular expressions is a must have at all ;) .

So, please...

Greets,
Johannes Neubauer.

[Matthew L. Avizinis]

my 2¢ worth:
I for one would like to see this. I've played around with Saxon and
find that xslt2 is easier to write, read, and maintain. I've been
thinking about switching a project I've been working on where I work to
Saxon for this reason (among others), but I'd miss the nice
extensibility that Xalan has with its scriptable Java/Javascript (makes
it nice to include processor extension functions right in a stylesheet)
and its exslt support.
Unfortunately, wouldn't be able to contribute much other than reporting
potential bugs when encountered.
Matthew L. Avizinis
Gleim Publications, Inc.

Post by Henry Zongaro
Hi, Johannes.
I'm cross-posting to both mailing lists to make sure we have broad
coverage for this discussion. Everyone, please follow up on
xalan-j-users.

Will future releases of Xalan-J definitively support XSLT 2.0 and XPath
2.0?
I searched the user and dev mailing lists and found only 4 year old
postings that say that there will be XSLT 2.0 implementations in future
Xalan-J Releases. Furthermore I found the xslt20/ and xslt20-compiled/
branches in the SVN repositories, but 4 years passed since the last
checkin, too.

Speaking as a committer on the Apache Xalan project, I'd certainly be
interested in seeing an XSLT 2.0 implementation take shape here. I'd
like to find out how much interest there is from others in seeing an
open source XSLT 2.0 implementation from the ASF. If you're
interested in such an implementation (as a user), please respond and
let us know which features you're most interested in. And conversely,
I would also like to hear from any users who are satisfied with an
XSLT 1.0 processor, and not much interested in migrating to XSLT 2.0.
Feel free to respond either on the mailing list or to me directly, in
private. I'll summarize the results of this informal polling in a
week or so.

In another mail-archive (not in a apache related) I found a posting that
claimed that a apache programmer has said that there won't come any
implementations for the new specifications, because the management does
not agree with them.

For the benefit of the list, I thought I should mention that you told
me in a private e-mail that you later realized it was a developer on a
different XSLT processor (not an Apache Xalan developer) who said they
had no interest in XSLT 2.0.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro XSLT Processors Development
IBM SWS Toronto Lab T/L 969-6044; Phone [phone]

[Eric J. Schwarzenbach]

My company also is moving toward switching to Saxon, even if only the
free version, for XSLT 2.0 support, as well as expected performance
gains (though whether the free, open-source Saxon-B also out-performs
Xalan, as the commercial Saxon-SA seems to, is not clear to me;
certainly comments from Xalan folk on that matter would be of interest).

I must say lack of even any public statement of intentions in the web
site, with regard to XSLT 2.0, as well as the 6 month silence between
the delay of the intended 2.71 version and the next mention of it, has
made us wonder seriously about the future of Xalan. I don't say this to
be critical of the folks generously giving their time to this project,
but just to point out what appearances may be saying (correctly or
incorrectly) to people assessing the competitiveness of the the XSLT
products out there.

Eric Schwarzenbach

Post by Matthew L. Avizinis
I for one would like to see this. I've played around with Saxon and
find that xslt2 is easier to write, read, and maintain. I've been
thinking about switching a project I've been working on where I work to
Saxon for this reason (among others), but I'd miss the nice
extensibility that Xalan has with its scriptable Java/Javascript (makes
it nice to include processor extension functions right in a stylesheet)
and its exslt support.
Unfortunately, wouldn't be able to contribute much other than reporting
potential bugs when encountered.
Matthew L. Avizinis
Gleim Publications, Inc.

Post by Henry Zongaro
Hi, Johannes.
I'm cross-posting to both mailing lists to make sure we have broad
coverage for this discussion. Everyone, please follow up on
xalan-j-users.

Will future releases of Xalan-J definitively support XSLT 2.0 and XPath
2.0?
I searched the user and dev mailing lists and found only 4 year old
postings that say that there will be XSLT 2.0 implementations in future
Xalan-J Releases. Furthermore I found the xslt20/ and xslt20-compiled/
branches in the SVN repositories, but 4 years passed since the last
checkin, too.

Speaking as a committer on the Apache Xalan project, I'd certainly be
interested in seeing an XSLT 2.0 implementation take shape here. I'd
like to find out how much interest there is from others in seeing an
open source XSLT 2.0 implementation from the ASF. If you're
interested in such an implementation (as a user), please respond and
let us know which features you're most interested in. And conversely,
I would also like to hear from any users who are satisfied with an
XSLT 1.0 processor, and not much interested in migrating to XSLT 2.0.
Feel free to respond either on the mailing list or to me directly, in
private. I'll summarize the results of this informal polling in a
week or so.

In another mail-archive (not in a apache related) I found a posting that
claimed that a apache programmer has said that there won't come any
implementations for the new specifications, because the management does
not agree with them.

For the benefit of the list, I thought I should mention that you told
me in a private e-mail that you later realized it was a developer on a
different XSLT processor (not an Apache Xalan developer) who said they
had no interest in XSLT 2.0.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro XSLT Processors Development
IBM SWS Toronto Lab T/L 969-6044; Phone [phone]

[Klaus Malorny]

Post by Henry Zongaro
Feel free to respond either on the mailing list or to me directly, in
private. I'll summarize the results of this informal polling in a week
or so.

Although I haven't used XSLT 2.0/XPath 2.0 yet, I would greatly like to see
Xalan supporting this. I have done numerous projects using XSLT and hit several
times the limitations of 1.0 -- be it due to the very limited string
functionality or to the inability to reprocess result tree fragments. This often
resulted in highly inefficient, recursive and tricky code or even in splitting
of the processing into multiple steps. Looking into the 2.0 specs, it seems that
I could solve a lot of my previous problems in a quite comfortable way. Also, I
think that Sun has to move to 2.0 for the JDK at some point in time, and it
would be quite sad if they had to choose a different implementation.

Regards,

Klaus

[Johannes Neubauer]

If you're interested in such an implementation (as a user), please
respond and let us know which features you're most interested in. And
conversely, I would also like to hear from any users who are satisfied
with an XSLT 1.0 processor, and not much interested in migrating to
XSLT 2.0.

Another feature I would like to have, is an easy way for using an
existing DOM tree as the input of a XSLT script.

A XSLT to "native" Java compiler would be great, too.

The Batik project could benefit from an implementation, too. XSLT
transformations on an SVG-DOM could manipulate an SVG document...

Greets,
Johannes Neubauer.

[Henry Zongaro]

Hi, Johannes.

Post by Johannes Neubauer

If you're interested in such an implementation (as a user), please
respond and let us know which features you're most interested in. And
conversely, I would also like to hear from any users who are satisfied
with an XSLT 1.0 processor, and not much interested in migrating to
XSLT 2.0.

Another feature I would like to have, is an easy way for using an
existing DOM tree as the input of a XSLT script.

Could you elaborate on this? I assume that you want to do something other
than the following, but I'm not sure what:

Transformer t = ...;
t.transform(new DOMSource(domNode), new StreamResult(...));

Post by Johannes Neubauer
A XSLT to "native" Java compiler would be great, too.

Again, could you elaborate? The Xalan project does have XSLTC, which
generates Java classes. Are you looking for something that generates Java
source code that you could then modify? Or do you have some other
requirement?

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro XSLT Processors Development
IBM SWS Toronto Lab T/L 969-6044; Phone [phone]
mailto:***@ca.ibm.com

[Johannes Neubauer]

Hi Henry,

Post by Henry Zongaro
Could you elaborate on this? I assume that you want to do something
Transformer t = ...;
t.transform(new DOMSource(domNode), new StreamResult(...));

That's what I meant. Of course it would be a performance enhancement,
but not standard conform to have some templates that match a document
only partly and replace/enhance them with new nodes but work on the
source tree all the time. This way I could write something like this:

import org.w3c.dom.Document;

void magicTransform(Document dom) {
Transformer t = ...;
t.transform(dom);
}

void transformCallerWithDOMTreebyReference(Document dom) {
magicTransform(dom);
new DOMViewer(dom).setVisible(true);
}

If this is not conform to the standard this would suffice:

import org.w3c.dom.Document;

Document magicTransform(Document dom) {
Transformer t = ...;
return t.transform(dom);
}

void transformCallerWithDOMTreebyReference(Document dom) {
new DOMViewer(magicTransform(dom)).setVisible(true);
}

There might be the necessity to put the dom tree into a wrapper and wrap
the result back to a dom tree, but the last example showed the
"principle". Did this answer your question? I would like to use this for
manipulating a SVG-DOM-Tree for example.

Post by Henry Zongaro

Post by Johannes Neubauer
A XSLT to "native" Java compiler would be great, too.

Again, could you elaborate? The Xalan project does have XSLTC, which
generates Java classes. Are you looking for something that generates
Java source code that you could then modify?

I meant XSLTC for XSLT 2.0 ;) .

Post by Henry Zongaro
Or do you have some other requirement?

* A schema validator would be great ;). I don't know if there is already
an Apache project.

* A standalone XPath 2.0 engine and a XPath 2.0 engine for searching
sequences of nodes and atomic types in DOM trees. There is already XPath
1.0 support.

Perhaps next year I have more spare time and can submit a little
bit :) .

Greets,
Johannes Neubauer.

[kingargyle]

If you're interested in such an implementation (as a user), please
respond and let us know which features you're most interested in. And
conversely, I would also like to hear from any users who are satisfied
with an XSLT 1.0 processor, and not much interested in migrating to
XSLT 2.0.

I'm pinging and reviving this thread as there hasn't been any response on
this front in over a year. It's hard to believe that the Xalan corporate
users don't have a need for XSLT 2.0 support. I work on the XSL Tools
project at eclipse, and have several requests to add XSLT 2.0 debugging
support. However, we can't use Saxon due to some obscure IP concerns, so
that leaves us with no way to provide XSLT 2.0 debugging or XPath 2.0
support out of the box.

XSLT 2.0 is becoming more prevelant in it's usage and adoption, for many of
the reasons that have been previously mentioned.

[Henry Zongaro]

Hello.

I'd like to find out how much interest there is from others in
seeing an open source XSLT 2.0 implementation from the ASF. If
you're interested in such an implementation (as a user), please
respond and let us know which features you're most interested in.
And conversely, I would also like to hear from any users who are
satisfied with an XSLT 1.0 processor, and not much interested in
migrating to XSLT 2.0.
Feel free to respond either on the mailing list or to me directly,
in private. I'll summarize the results of this informal polling in
a week or so.

I received eight (8) responses in which users indicated that they would
like to see an open source implementation of XSLT 2.0 from the ASF. The
following features were mentioned as most desirable:

o Schema validation
o xsl:for-each-group
o xsl:analyze-string
o Regular expression support
o Applying path expressions to temporary trees
o Expanded repertoire of string functions
o Streaming capability for large documents

I should note that streaming capability isn't something that's really
changed from XSLT 1.0 to XSLT 2.0.

One respondent indicated that they like Xalan-J's support for Java and
scripting extension functions, and that having those facilities in an XSLT
2.0 implementation would make for a very desirable processor.

One respondent wanted Xalan to be as feature-rich as possible, but was
unsure whether their customers would require XSLT 2.0 features. That
particular respondent didn't want Xalan's lack of XSLT 2.0 features to
impede customers, but indicated that that hasn't happened yet. I didn't
include that response among the positive responses I received.

Nobody indicated that they are satisfied with XSLT 1.0.

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro XSLT Processors Development
IBM SWS Toronto Lab T/L 969-6044; Phone [phone]
mailto:***@ca.ibm.com