[
https://issues.apache.org/jira/browse/XALANJ-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17830617#comment-17830617
]
Joseph Kessselman edited comment on XALANJ-2734 at 3/25/24 5:42 PM:
--------------------------------------------------------------------
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.
I'm less certain about merging it into Xalan as it stands, bound to the default
namespace.
Doesn't have to be resolved right now. I just wanted to bring it up since I
think we're close to trusting the Maven-based build enough to release that, and
then to hopefully start doing more frequent releases as fixes get applied.
Feel free to close this request as "won't do", if you wish.
was (Author: jkesselm):
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.
I'm less certain about merging it into Xalan as it stands, bound to the default
namespace.
Doesn't have to be resolved right now. I just wanted to bring it up since I
think we're close to trusting the Maven-based build enough to release that, and
then to hopefully start doing more frequent releases as fixes get applied.
> 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: Bug
> 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 architecture's base assumptions.
> I'd sorta like to stop having a completely separate branch for the 3.0
> experiments. Making them part of the Xalan Extensions Library is the best
> idea I have for bringing them into the main branch any time soon.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
