[
https://issues.apache.org/jira/browse/XALANJ-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830871#comment-17830871
]
Mukul Gandhi commented on XALANJ-2734:
--
(1) OK. I was just suggesting this because it would give us a clean way to get
the XSLT 3.0 subset out in front of the public, and maintained as part of the
standard Xalan product, rather than having it be off in a separate build. It
would also avoid having to keep two branches in synch on an ongoing basis.
[mukul]
Following is another idea, to handle this,
We may have two Xalan codebases parallel to each other on dev repos branch
'master', and only one build shall handle those (the current maven build on dev
repos branch 'master', needs to be modified to handle Xalan XSLT 3.0 work as
well from dev branch xalan-j_xslt3.0).
With this, a single Xalan build on branch 'master', shall produce two Xalan
jars. One will be for XSLT 1.0, and other shall be for XSLT 3.0 subset.
(2) I'm less certain about merging it into Xalan as it stands, bound to the
default namespace.
[mukul]
I think, that we should not change Xalan implementation of following (that's
specified within XSLT stylesheets) for Xalan's XSLT 3.0 subset work,
http://www.w3.org/1999/XSL/Transform; ...
This shall be less of a problem, when Xalan's XSLT 3.0 subset work gets built
along with 1.0 work from Xalan's branch 'master'.
> Can the partial/prototype XSLT 3.0 logic be made into Xalan Extensions?
> ---
>
> Key: XALANJ-2734
> URL: https://issues.apache.org/jira/browse/XALANJ-2734
> Project: XalanJ2
> Issue Type: Wish
> Security Level: No security risk; visible to anyone(Ordinary problems in
> Xalan projects. Anybody can view the issue.)
>Reporter: Joseph Kessselman
>Assignee: Mukul Gandhi
>Priority: Major
>
> There has been work in progress (thanks, Mukul) to create a version of Xalan
> extended with some features from XSLT 3.0, and perhaps 3.1.
> My understanding (which may be wrong) is that to date this work has been done
> by directly adding the new functionality to core Xalan, within the default
> XSLT namespaces.
> A better solution, where possible, might be to treat these as Xalan
> extensions as described in [https://xml.apache.org/xalan-j/extensionslib.html
> |http://example.com].
> The details of coding these can be found at
> [https://xml.apache.org/xalan-j/extensions.html|https://xml.apache.org/xalan-j/extensions.html.]
> That would put the new functions and elements in a Xalan-specific namespace
> from XSLT 2.0, requiring that they be prefixed when invoked and that these
> namespaces be declared before accessing them. Yes, it's less pretty, but it
> makes the portability issue explicit. It also makes clearer that the new
> functionality may not be available in compiled mode yet, and provides some
> templates for implementing the latter.
> Note that extensions can implement elements as well as functions. I would
> argue that if there is a 3.0 change to an element's behavior, we should
> create an extension element to provide that behavior, even if it is largely a
> copy of or a wrapper of our 2.0 implementation, to make the new behavior
> available only when explicitly referenced as an extension. That limits any
> risk of conflict between old and new definitions.
> There is the question of what namespace to use for these. I can see arguments
> both for keeping them in a Xalan-defined namespace, and for using the
> XSLT3/XPath3 namespaces for them. I would want to be able to guarantee strict
> compliance of these functions/elements with the W3C Recommendations before
> presuming to use W3C's namespaces for them, so I'd lean toward keeping them
> in a Xalan-owned namespace for now, The XSLT3.0 community might have opinions
> on this.
> With that clear division between what is part of a compatible XSLT 2.0
> implementations and what is not, I'd be willing to consider releasing the new
> features as part of Xalan, clearly documented as not representing a full 3.0
> implementation... much the way we added implementations of EXSLT to the
> system. Note that some of EXSLT actually anticipates XSLT 3.0 features, and
> demonstrates how to make them work with Xalan.
> Ideally, there would be minimal change needed to the base Xalan code, thus
> minimizing risk of regression unless the extentions are being used. If deeper
> modifications to the data or processing model are required, we might not want
> to include those in our product stream until we are willing to properly
> consider upgrading the whole engine to a recent version of the W3C
> standards... which, if our experience moving from 1.0 to 2.0 was any
> indication, involves a much larger and more systematic reconsideration of the
> entire
