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 26308 - [xslt 3.0] true|false as synonymns for yes|no
Summary: [xslt 3.0] true|false as synonymns for yes|no
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Working 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: 2014-07-11 09:42 UTC by Michael Kay
Modified: 2014-08-02 14:00 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2014-07-11 09:42:40 UTC
In response to email discussion the XSL WG yesterday accepted a proposal to allow the values true|false and 1|0 as synonymns for yes|no in XSLT attributes that accept yes|no values.

There are two rationales for this:

(a) to allow boolean values to be used in AVTs and shadow attributes, for example

<xsl:param name="terminate" as="xs:boolean"/>
<xsl:message terminate="{$terminate}"/>

<xsl:param name="streamable" as="xs:boolean" static="yes"/>
<xsl:mode _streamable="{$streamable}"/>

(b) consistency with XML Schema

This bug is being raised to record this decision.
Comment 1 Abel Braaksma 2014-07-15 01:34:21 UTC
There is a small, but possible compatibility issue with AVTs (not for static attributes, as they would not compile). 

The incompatibility is that an AVT with a wrong dynamic value would raise a dynamic error for true|false or 0|1.  It is probably only an issue where a rigorous testing framework is meant to test such situations and expect them to fail, where in XSLT 3.0 they would now succeed.

Not a big compatibility issue, but we might want to mention it nevertheless.
Comment 2 Abel Braaksma 2014-07-15 16:22:30 UTC
Closing the bug per the answer from Michael Kay in https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Jul/0025.html (member only), saying that for changes that resolve error-conditions, there is no need to express the compatibility issues.
Comment 3 Michael Kay 2014-08-02 14:00:55 UTC
The change has been applied to the spec.