Subject: Re: [xsl] Designing streamable XPath expressions From: Michael Kay <mike@xxxxxxxxxxxx> Date: Sun, 5 Jan 2014 23:42:21 +0000 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Designing streamable XPat, Dimitre Novatchev | Thread | Re: [xsl] Designing streamable XPat, Dimitre Novatchev |
Re: [xsl] Designing streamable XPat, Dimitre Novatchev | Date | Re: [xsl] Designing streamable XPat, Liam R E Quin |
Month |