This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The first two following questions were originally reported to me by my programmer, Eugene Fotin. While implementing the new xsl:merge syntax, we stumbled upon the following questions, to which I believe the specification has no clear answer: > what error should be raised if both @for-each-stream and @for-each-item are present? I think that, in line with similar constructs that have mutual exclusive attributes, we should introduce a specific static error condition for this. > what to do when @for-each-stream is present and streamable="no" > is absent? From the current text, the semantics of for-each-stream are described in terms of streamability. I think that in the case of the effective value of streamable="no", the behavior should be similar to the fn:collection function (except that its arguments do not return collections, the behavior is more like fn:document), i.e., whether or not it is stable is implementation dependent. If we mean that, I think we should say so explicitly. > 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. Why not change the argument to be xs:anyURI*? Then a type error would be the logical error if an argument is not a URI. > 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). We are more explicit about error conditions with fn:streaem-available, stipulating the errors of fn:doc-available that it inherits. I think it is worth mentioning this for xsl:stream and xsl:merge/@for-each-stream as well.
*** Bug 26765 has been marked as a duplicate of this bug. ***
> 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).
The WG agreed with the proposed changes.
I will take the opportunity to add xsl:stream and xsl:merge-source to the list of elements to which error XTSE1505 applies (validation and type are mutually exclusive).
I have also taken the opportunity to specify, for avoidance of doubt, that [xsl:]default-validation has no effect on whether xsl:stream and xsl:merge-source perform validation; they perform no validation unless explicitly requested.
Comment #3 is an misrepresentation of the WG decision, especially for para 2. Here is the actual decision: DECISION para 1: the WG accepted allocating an error code for the mutual exclusive arguments DECISION para 2: instead of the proposed solution, the WG agreed with requiring streamable="yes" if for-each-stream attribute is present DECISION para 3: no change, xs:string is in line with other functions and constructs DECISION para 4: marked editorial, to add error conditions
Changes applied. The error code allocated is XTSE3195: <error class="SE" code="3195"><p>The two attributes <code>for-each-item</code> and <code>for-each-stream</code> are mutually exclusive. The <elcode>xsl:merge-source</elcode> element may contain either or neither, but not both. It is a <termref def="dt-static-error"/> if both are present. Furthermore, if the <code>for-each-stream</code> attribute is present, the only permitted value (and the default value) of the <code>streamable</code> attribute is <code>yes</code>. </p></error>