Re: [xslt] XSLT 2.0

[Steve Ball <Steve Ball explain com au>]

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