This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
During the telcon of 13 March 2014, during the discussion about xsl:try and streaming, one suggestion that was made in addition to solving the xsl:try buffering issue, was to be able to query whether a streaming document is available or not. If we decide to introduce such a function, it can never be a stable function, because streaming documents are not stable upon multiple invocations. However, we can define such a function such that it must attempt to read up to the start of the root note and buffer this for a next invocation of the same URI. Example: <xsl:stream href="{ if(streaming-document-available($x)) then $x else $y}"> .... </xsl:stream>
Related: bug 25174.
During the telcon of 15 May 2014 this bugreport was discussed and the WG requested what semantics the new function should have. I propose to have it have the same semantics we currently use for reading a streamed document: we currently say that a streamed document must buffer the part up until the root element, and that the DTD, PI's and comments prior to the root element must be buffered. I think it makes sense to define it in terms of existing functionality, similarly to the way the XPath function fn:doc-available is defined: Summary The function returns true if a streaming document is available. Signature fn:streaming-document-available($uri as xs:string?) as xs:boolean Properties This function is [non-deterministic], [context-dependent] and [focus-independent], it depends on the static base uri. Rules If $uri is the empty sequence, this function returns false. If the following construct returns true, this function returns true: <xsl:stream href="{$arg}"> <xsl:value-of select="has-children(root())" /> </xsl:stream> Error conditions (should we raise FODC0005 if the uri is not well-formed?) Otherwise, this function returns false. Notes If this function returns true, implementers are encouraged to buffer the result of reading up until the root element so that an <xsl:stream> instruction with the same URI will succeed, even in scenario's where reading a streaming document is forward-only. However, this behavior is not guaranteed for the same reasons multiple invocations of <xsl:stream> on the same URI are not guaranteed deterministic. This means in practice that this function returns a positive hint that a document is or is not available, but subsequent invocations using <xsl:stream> with the same URI may still fail.
OK in principle, but I think my preference would be (a) name the function stream-available() (b) define it along the following lines: the function returns true if and only if all the following conditions are satisfied: * The URI is valid, * a resource with this URI can be retrieved * the initial bytes of the resource can be read and decoded as text according to the rules used by an XML processor * the resulting sequence of characters starts with a string that matches the grammar: prolog (EmptyElemTag | STag ) as defined in the XML Recommendation * no implementation-dependent errors, such as would cause the xsl:stream instruction to fail, are detected during the process of opening and parsing the initial content of the stream
I just checked the XML grammar to be sure I understand it correctly: Prolog: xml decl and/or dtd and/or SI/comment/whitespace STag: start tag of element EmptyElemTag: empty element tag so I think this is the same as matching has-children(root()), except explained in XML grammar and without the potential confusion about consuming the input to process the xpath instruction. I am unsure about your last paragraph, what implementation dependent errors could raise that allow to read to STag but would still throw? > * The URI is valid, while I think this is preferable, do note that it is a deviation from the semantics of fn:doc-available(), which throws here.
The proposal in comment 3 was accepted today.
Applied to spec.