[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Designing streamable XPath expressions

Subject: Re: [xsl] Designing streamable XPath expressions
From: Michael Kay <mike@xxxxxxxxxxxx>
Date: Sun, 5 Jan 2014 21:16:19 +0000

> What is the XSLT working group's plans for supporting the streaming of

The plan is to leave it entirely to implementations.

We don't feel there is any need for new language constructs in this area. Most
of the operators and functions on strings (matches, translate, tokenize,
replace, starts-with, etc) are in principle streamable if implementors
consider that this use case is significant. If there is no need for language
changes to support a feature then the WG doesn't need to get involved: it's
solely a performance issue.

(It's not the purpose of the WG to act as a pressure group for users to press
their requirements on implementors. If some users want support for 1Gb text
nodes, and no implementors provide such support, then that's purely a
marketplace issue; perhaps the users who want the feature aren't prepared to
pay enough for the feature to justify implementors making the investment.)

I looked into Saxon limits recently and found that supporting very large text
nodes would be prohibitively expensive because of the lack of support from the
Java platform. I've also looked at supporting common operations like
tokenize() on strings that are not entirely in memory and it's quite difficult
because it has a very disruptive effect on the design of the regular
expression engine (no backtracking allowed).

Michael Kay

Current Thread