Re: [xslt] XSLT 2.0
- From: Steve Ball <Steve Ball explain com au>
- To: The Gnome XSLT library mailing-list <xslt gnome org>, Tony Graham MenteithConsulting com
- Subject: Re: [xslt] XSLT 2.0
- Date: Tue, 10 Jun 2008 10:31:05 +1000
On 06/06/2008, at 7:18 AM, Tony Graham wrote:
On Thu, Jun 05 2008 07:57:07 +0100, Steve Ball explain com au wrote:
...
I also don't have a lot of time for this, but can't we (meaning the
whole libxml2 community) share the effort to achieve this? The
problem
There probably are enough libxslt users that there would be quite a
few
of those users who could gainfully contribute, but that raises the
question of why there aren't more than the dedicated few currently
working on libxslt.
That's the same with many (most?) open source projects...
can be broken down into modules and I believe that at least some of
But someone or some group would first need to work out what they are
and
how they fit together.
That's what I would do first.
these may be implemented independently. For example, XPath 2 has a
new
syntax, plus sequences, FLWR expressions, etc, but the language is
separate to the XPath operators and functions. Also, XSLT 2 would
need
to be upgraded to support temporary trees, sequences, etc, but many
of
the new elements could be implemented separately, such as for-each-
group, regular expressions, etc.
There's also the whole W3C XML Schema-ness that underlies much of XSLT
2.0 and that was seen as a sticking point for a 2.0 version five years
ago [1].
This is what encourages me to use libxml2/libxslt as a starting point
- there's already a XML Schemas implementation onboard.
The static and dynamic error checking and reporting in the terms of
the
error codes in the specs would also have to be worked out before
people
dove into separate modules.
See above. There's a bit of up-front design work to be done.
It goes without saying that it would be preferable not to fork
development for XSLT 2, but rather to create a branch to later be
merged back into the main project development.
I'm more inclined to suspect it would be a branch that never merged
back
into the XSLT 1.0 trunk, though I also suspect it would try very
hard to
maintain the same xsltApplyStylesheet(), etc., API so the 2.0 version
could be a drop-in replacement for the current libxslt.
Fair enough.
Who is willing to help out with this effort?
I would be willing, but I have other commitments on my open source
free
time.
Don't we all... ;-)
Cheers,
Steve Ball
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]