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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
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: [hidden email]
          Reporter: [hidden email]
        QA Contact: [hidden email]

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.

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26765

Abel Braaksma <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #1 from Abel Braaksma <[hidden email]> ---
Sorry for the double post, closing this as duplicate, it has terrible layout
done by the BugZilla renderer, and is therefor almost unreadable.

*** This bug has been marked as a duplicate of bug 26766 ***

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