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

Re: [xsl] Designing streamable XPath expressions

Subject: Re: [xsl] Designing streamable XPath expressions
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Sun, 5 Jan 2014 18:26:58 -0800

On Sun, Jan 5, 2014 at 3:42 PM, Michael Kay <mike@xxxxxxxxxxxx> wrote:

> It can also fail because of limits unrelated to streaming. A processor might fail because it has a limit of 256 characters, or 256k characters, for the length of
> element names, or a limit of 18 digits, or 18K digits, on the length of an integer, or a limit of 2K bytes, or 2G bytes, on the size of an attribute, and all these
> failures might occur whether or not there is enough memory available. XSLT 3.0 does not attempt to solve these problems.
> In addition, a streaming processor can fail due to insufficient memory because the document tree is too deep. For example, a processor might run out of memory > if the tree has a depth greater than 10,000.
> The point here is that the specification is attempting to solve practical use cases arising in real life. The WG has been influenced throughout by practical
> problems, not theoretical problems. The use cases that the WG has taken into consideration have involved documents with large numbers of nodes, but no-one > has provided practical use cases involving very large text nodes, or very deep trees.

Then, in this case the specification must clearly say so. What it
contains now is (at:

"This specification does not attempt to legislate precisely what
constitutes evaluation "using streaming". The most important test is
that the amount of memory needed should be for practical purposes
independent of the size of the source document, and in particular that
the finite size of memory available should not impose a limit on the
size of source document that can be processed."

We know that the property expressed by the statement after the last
comma in the citation above, doesn't actually hold in the case of huge
text nodes and in the case of big tree depth. And there is nothing
alerting us to this fact. On the contrary, the term
"guaranteed-streamable" makes the reader believe that if the specified
rules are not violated, then the XSLT transformation is
guaranteed-streamable. If there are actually exceptions to this
guaranteed streamability, they need to be mentioned, in order not to
leave the impression that the phrase "guaranteed-streamable" has. It
is a good design practice to specify what is out of scope for a given

> Use cases involving very large unparsed text files have been addressed at least in part by the introduction of unparsed-text-lines()

I am re-reading the specification of unparsed-text-lines() at:


and there is no mention of any relation of this function to streaming,
or "very large unparsed text files",

Therefore, it seems not obvious how cases involving very large
unparsed text files have been addressed, even in part, by the
introduction of the unparsed-text-lines() function.

Is this omission in the F & O Specification?

Dimitre Novatchev
Truly great madness cannot be achieved without significant intelligence.
To invent, you need a good imagination and a pile of junk
Never fight an inanimate object
To avoid situations in which you might make mistakes may be the
biggest mistake of all
Quality means doing it right when no one is looking.
You've achieved success in your field when you don't know whether what
you're doing is work or play
To achieve the impossible dream, try going to sleep.
Facts do not cease to exist because they are ignored.
Typing monkeys will write all Shakespeare's works in 200yrs.Will they
write all patents, too? :)
I finally figured out the only reason to be alive is to enjoy it.

Current Thread