[
https://issues.apache.org/jira/browse/XALANJ-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17830540#comment-17830540
]
Mukul Gandhi commented on XALANJ-2734:
--------------------------------------
[~jkesselm], I think Xalan extension mechanism to create custom XSLT extension
elements is a nice feature provided by Xalan. I believe that, Xalan extension
element feature, should be used to implement extension elements that're not
part of XSLT specification.
What you're suggesting within this jira issue, is to redo all the XSLT 3
implementation code we've written on the Xalan dev repos branch xalan-j_xslt3.0
and convert those XSLT 3 native element implementations into Xalan extension
elements. IMHO, but this doesn't look right to me :(, since we've already
implemented many XSLT 3 instructions natively, which is lot of new XSLT 3
compliant code (we've already spent it seems about nearly one year of work
effort on this) we've written on the dev repos branch xalan-j_xslt3.0.
When we started work on Xalan's XSLT 3.0 implementation on dev repos branch
xalan-j_xslt3.0, we decided with consensus to try implementing a compliant XSLT
3.0 processor for Xalan.
Had we been in the situation, when the amount of implementation code was less
and the implementation was not stable (we're not yet much compliant to the
relevant XPath spec for Xalan's XSLT 3 implementation, but for XSLT
instructions newly introduced within 3.0 spec Xalan's compliance is nice), we
could have discarded that and could have restarted implementing those as Xalan
extension elements.
> 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
