[Bug 26766] [XSLT30] xsl:merge implementation issues, error conditions and non-streaming behavior

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26766

--- Comment #2 from Michael Kay <mike@saxonica.com> ---
> what error should be raised if both @for-each-stream and @for-each-item are present?

Agreed, for consistency we should allocate an error code.

> what to do when @for-each-stream is present and streamable="no" is absent?

Presumably you mean streamable="yes" is absent?
I would say, treat for-each-stream="XX" as if they had written
for-each-item="(XX)!doc(.)".

> the type of @for-each-stream is xs:string*, however the spec 
> demands it to return uris, in fact, this is a MUST. Making it 
> just xs:string* seems too liberal.

It is our consistent practice to accept xs:string where a URI is required, e.g.
in doc(), xsl:stream, resolve-uri() etc. An xs:anyURI is OK, because of type
promotion.

> the behavior of dereferencing the uris is described as the 
> same as fn:doc. Does this preclude raising the same errors 
> if dererencing fails? (this remark also applies to xsl:stream, 
> which defines no errors of its own).

Yes, we should add this: The process of obtaining a document node given a URI
is the same as for the docFO30 function (including error conditions).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 10 September 2014 11:00:07 UTC