So any XSLT 3.0 user should know that although a transformation is
"streamable" according to the standard, it can crash at any moment, in
any given execution, due to ... well, lack of support for streaming
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. Use cases involving very large unparsed text files have been addressed
at least in part by the introduction of unparsed-text-lines(), but beyond that,
it was felt that if implementors wanted to support text nodes of infinite size
there was nothing in the specification that inhibited them from doing so.
Michael Kay
Saxonica
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--