[
https://issues.apache.org/jira/browse/XALANJ-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Kessselman updated XALANJ-2734:
--------------------------------------
Issue Type: Wish (was: Bug)
> 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 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
