Interestingly, I can see at this location http://svn.apache.org/repos/asf/xalan/java/branches/, following folders
xslt20 & xslt20-compiled Any thoughts, what is the functionality currently contained in above folders? On Sat, May 26, 2018 at 11:41 AM, Mukul Gandhi <[email protected]> wrote: > Hi all, > I've been tempted to bring this topic again, to this list. I think it'd > be really great for Xalan to have a XSLT 2.0 processor as well (its 1.0 > processor is just great). I'll attempt to enumerate following options with > my notions of pros-and-cons, for Xalan to provide an XSLT 2.0 processor as > well, > 1) Natively enhance Xalan's current XSLT 1.0 processor to a 2.0 processor, > in a branch of its own. The effort and time to market for this, would be > highest. > 2) Use Eclipse's XPath 2.0 processor (also known as PsychoPath XPath 2.0 > processor), in the XSLT 2.0 codebase which Xalan would develop. This option > saves us the effort of writing a native XPath 2.0 processor. But perhaps > the cons is that, PsychoPath XPath 2.0 processor can accept only the DOM > input to convert it to XDM. > 3) Is there any possibility of IBM donating in some way its XSLT 2.0 > processor technology to Xalan? If it can be done, people will flock to the > IBM derived Xalan's XSLT 2.0 processor. > 4) Can we use Saxon's latest home edition XSLT 2.0 processor (its open > source), and convert to to Xalan's XSLT 2.0 processor? I believe, Saxon's > open source products come with Mozilla Public License, and I'm not sure how > suitable it is for having it in Xalan? > > I'd also suggest, that any XSLT 2.0 processor from Xalan should be > schema-aware using Xerces's XSD processor. > > I'm still not thinking about XSLT 3.0, which is already a W3C spec. I > think we should have XSLT 2.0 first. > > Needless to say, I'll be happy to participate in any such work. > -- Regards, Mukul Gandhi
