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