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

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

[Bug 26766] 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=26766

            Bug ID: 26766
           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"
> 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 26766] [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=26766

--- Comment #1 from Abel Braaksma <[hidden email]> ---
*** Bug 26765 has been marked as a duplicate of this bug. ***

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

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26766

--- Comment #2 from Michael Kay <[hidden email]> ---
> 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.

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26766

Michael Kay <[hidden email]> changed:

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

--- Comment #3 from Michael Kay <[hidden email]> ---
The WG agreed with the proposed changes.

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

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26766

--- Comment #4 from Michael Kay <[hidden email]> ---
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).

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

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26766

--- Comment #5 from Michael Kay <[hidden email]> ---
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.

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

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26766

--- Comment #6 from Michael Kay <[hidden email]> ---
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

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

Reply | Threaded
Open this post in threaded view
|

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

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26766

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #7 from Michael Kay <[hidden email]> ---
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>

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