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

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

            Bug ID: 26765
           Summary: [XSLT30] xsl:merge implementation issues, error
                    conditions and non-streaming behavior
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org

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" or 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.

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

Received on Tuesday, 9 September 2014 23:08:07 UTC