26766 2014-09-09 23:10:45 +0000 [XSLT30] xsl:merge implementation issues, error conditions and non-streaming behavior 2014-09-12 09:57:53 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC Windows NT CLOSED FIXED P2 normal --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 111304 0 abel.braaksma 2014-09-09 23:10:45 +0000 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. 111306 1 abel.braaksma 2014-09-09 23:11:58 +0000 *** Bug 26765 has been marked as a duplicate of this bug. *** 111338 2 mike 2014-09-10 11:00:05 +0000 > 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). 111425 3 mike 2014-09-12 09:12:17 +0000 The WG agreed with the proposed changes. 111426 4 mike 2014-09-12 09:22:23 +0000 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). 111428 5 mike 2014-09-12 09:36:18 +0000 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. 111429 6 mike 2014-09-12 09:46:16 +0000 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 111430 7 mike 2014-09-12 09:57:53 +0000 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>