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

Reply via email to