Hi Joseph,
On Wed, Apr 12, 2023 at 9:39 PM Joseph Kesselman <kesh...@alum.mit.edu> wrote:
> If we just want to extend the existing Xalan architecture to add more recent
> functionality, it _is_ possible to do that on the main project, simply not
> declaring compatibility with the higher levels until they're complete and
> letting the incremental improvements be available for early experimentation
> (perhaps under control of a switch so the default is still strict 1.0
> compatibility.).
I've been thinking, along these lines as well, and this is not wrong I believe.
But if we''ll be using the same XalanJ codebase (i.e, on the same
XalanJ implementation branch), for both XSLT 1.0 and 3.0 and letting
users choose the XSLT processor version by a command line switch, or
an API feature setting, I think it'll be too early to do that around
these days, since XalanJ has no XSLT 3.0 implementation codebase just
now. Implementing such a XalanJ command line switch, or an API feature
setting, shall much clutter the XalanJ implementation for performing
different actions depending on the XSLT processor version chosen by
the user during XSLT transformation invocation.
IMHO, I personally prefer, having different XalanJ implementation
branches for 1.0 and 3.0 versions of the XSLT processor.
I've also been thinking to, gradually implementing few XSLT 3.0/XPath
3.1 features on a separate XalanJ branch, starting with things like
following:
1) Dropping result tree fragments data types from XalanJ
implementation and allowing users to natively do like following,
<xsl:variable name="temp">
<a>1</a>
<b>2</b>
</xsl:variable>
<xsl:value-of select="$temp/a"/> to be able to print value of XML
element "a" as in this example. i.e, instead of requiring users to use
exslt:node-set extension function.
2) Implementing XPath 3.1 regex features, like following,
fn:matches, fn:replace, fn:tokenize functions (ref,
https://www.w3.org/TR/xpath-functions-31/#string.match)
3) Implementing XPath 3.1 quantifier expressions (ref,
https://www.w3.org/TR/xpath-31/#id-quantified-expressions)
4) Implementing XSLT 3.0 grouping instruction and functions (ref,
https://www.w3.org/TR/xslt-30/#grouping)
We can start implementing, above XPath 3.1/XSLT 3.0 features on a
weakly/untyped XML input data (as within the current XalanJ
implementation), and gradually introducing strong data typing within
XalanJ using XML Schema language.
--
Regards,
Mukul Gandhi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
