This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24140 - [xslt 3.0] xsl:copy "must not generate any type errors"
Summary: [xslt 3.0] xsl:copy "must not generate any type errors"
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-19 14:14 UTC by Michael Kay
Modified: 2014-02-24 15:57 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2013-12-19 14:14:25 UTC
Under xsl:copy we say that the sequence constructor (under given conditions) "is not evaluated and must not generate any type errors."

This wording is potentially confusing; it could be read as meaning that it is an error it the sequence constructor generates any type errors, which would be a truism. The intended meaning, I think, is that if the processor DOES evaluate the sequence constructor then any errors in doing so must be masked. 

Perhaps it is also intended to mean that processors that normally do static type checking must not do so (or must mask any errors from so doing) in respect of the sequence constructor. However, this seems a bit too strong. If the instruction is

<xsl:copy select="$a">
  <xsl:value-of select="2 + 'London'"/>
</xsl:copy>

then it's unreasonable to stop the processor reporting a type error for the arithmetic expression. I think the real intended meaning is that there must be no type errors arising from the fact that the selected item is not an element or document node.
Comment 1 Michael Kay 2014-01-23 17:38:41 UTC
Discussed on 23 Jan, action on MHK to propose new wording
Comment 2 Michael Kay 2014-01-28 18:00:40 UTC
The current language is:

When the selected item is an atomic value or function item ... [or] when the selected item is an attribute node, text node, comment node, processing instruction node, or namespace node.... The sequence constructor is not evaluated, and must not generate any type errors.

The wording of the last sentence in 2.0 was simply:

The sequence constructor, if present, is not evaluated.

I'm going to propose that we move back to the 2.0 wording, and remove the phrase "and must not generate any type errors"; I can't think of any sensible way of distinguishing the kind of type errors it makes sense to raise from those it doesn't.

In fact I would propose another change, to say:

The sequence constructor is not evaluated.

on the grounds that the sequence constructor is always present (it may be empty, but it's always there).
Comment 3 Michael Kay 2014-01-30 18:15:53 UTC
The WG agreed to make this change.