This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
While I realize this subject is not new, it came up on the XSL List and Dimitry Novatchev sent me a direct note pointing to it: http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/201401/msg00019.html. The points raised in this discussion are: 1) large text nodes are not streamable (consider a large base64 chunk) 2) externally resourced unparsed-text is not streamable, only if you are lucky enough that unparsed-text-lines is processed using streaming, but the function itself is stable, so buffering the whole input can be required. Dimitry expressed his concern about both. I think we only need to address the second point, in the sense that we should allow something similar to: <xsl:stream unparsed-text-lines="http://example.com/largetext.txt"> <!-- each context item here is a line and is grounded --> </xsl:stream> The analysis of this is simple enough, the use-case is to allow multiple reads to be non-deterministic.
We discussed this at the face to face in Prague. We inclined to think that the problem described here might best be solved by exploiting the note in 1.6.4 of F & O: Some functions (such as fn:doc and fn:collection) create new nodes by reading external documents. Such functions are guaranteed to be ·deterministic· with the exception that an implementation is allowed to make them non-deterministic as a user option. That is, implementors can support a sublinear use of memory on unparsed text by allowing a user option to make the function non-deterministic.