On the one hand, I like the idea of doing test implementations of XSLT4 features to confirm that they *can* be implemented cleanly and to let people play with them.
On the other hand, I'm not sure running them against an XSLT2 dataset fully/correctly exercises them. My preference -- as with the 3.0 stuff, actually -- would be that if core changes to Xalan *aren't* required, we should release these as extension functions under a separate namespace. That's how the EXSLT extensions were introduced, before some of them were folded into XSLT3. It makes the line between core xalan and stuff that may not work on other processors much clearer. And (assuming a full implementation) it could still permit easily migrating a stylesheet to a true XSLT 3 or 4 processor just by changing the namespace binding to the official one. I'd be a lot happier with the idea of actually releasing these partial/prototype/experimental stubs as part of Xalan's product as extensions rather than as a forked version. That could also be easier for Mukul to maintain, isolating the extension set from the main body of the code except where core Xalan needs to expose a new API to support it. It also makes documenting what is and isn't 2.0 easier, and clarifies that our support priorities are likely to be focused mostly on 2.0 for now and that missing 3.0 features and incompatibilities with strict 3.0 behavior of these may be unavoidable until we can commit to a full upgrade. Mukul: I haven't looked at the 3.0 prototypes in any detail yet. Would it be possible to restructure them as an extension set? Would you be willing to do so? If you want to make these available for folks to start playing with, I think that would be the best path forward for them, and for early 4.0 experimentation too. -- /_ Joe Kesselman (he/him/his) -/ _) My Alexa skill for New Music/New Sounds fans: / https://www.amazon.com/dp/B09WJ3H657/ Caveat: Opinionated old geezer with overcompensated writer's block. May be redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant. ________________________________ From: Mukul Gandhi <gandhi.mu...@gmail.com> Sent: Friday, March 15, 2024 5:13:25 AM To: dev@xalan.apache.org <dev@xalan.apache.org> Subject: Re: xsl 4.0 draft specs, and xalan implementation Hi Gary, An w3c XSLT 4.0 community group home page introduces its work objectives as follows, "The group aims to agree extensions to the XSLT 3.0 Recommendation ..." And as per, the same XSLT 4.0 community group home page, its mentioned their that, the new XSL specifications shall be named with version number 4.0. We already have much (i.e, many of useful features) of XSLT 3.0 basic-conformance (there's little bit of [xml] schema aware implementation as well) related implementation available on, XalanJ's xslt 3.0 dev branch. I agree with your following statement, 'I imagine that best way to build a 4.0 processor is on top of a 3.0 processor'. The points that I've mentioned within my original mail within this mail thread, were my naive observations about XalanJ's current XSLT 3.0 implementation status. @IMHO, as can be seen I've also changed my mail subscription address to Xalan lists. On Thu, Mar 14, 2024 at 1:59 AM Gary Gregory <garydgreg...@gmail.com> wrote: > > I agree with Joe's concerns on architecture and resouces. > > I imagine that best way to build a 4.0 processor is on top of a 3.0 processor > and we don't have that out yet. > > It might be possible to cherry-pick some 4.0 features on top of our 2.x code > base like some new XPath functions for example, but I'm not sure that > wouldn't be confusing for our users (but it might be helpful). > > I would like us to be in the position to release 2.x at will in a maintenance > mode as we gear up for a 3.0, but that's just a personal preference. -- Regards, Mukul Gandhi --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org