W3C home > Mailing lists > Public > public-xsl-query@w3.org > May 2016

Re: ACTION A-641-13

From: Michael Kay <mike@saxonica.com>
Date: Sun, 8 May 2016 20:49:49 +0100
Cc: Public Joint XSLT XQuery XPath <public-xsl-query@w3.org>
Message-Id: <9376A394-3327-4261-B810-E939A0E9FCC5@saxonica.com>
To: Abel Braaksma <abel.braaksma@xs4all.nl>
> This section says "the supplied value must be of type xs:string or xs:untypedAtomic" (it doesn't say it can be a derived type of xs:string or xs:untypedAtomic). Neither is true (it is xs:NMTOKEN), so I think the cast should fail.

If a value is an instance of xs:NMTOKEN then it is also an instance of xs:string.
> Conversely, if the expression was " 'a' castable as xs:NMTOKENS", the cast would succeed.
> This seems to be expressed in 18.3 in the Note with "This approach does not work with list types, because it is not permitted to use a value of type xs:NMTOKEN* as input to the constructor function xs:NMTOKENS"

That sentence is not quite accurate. Firstly, "not permitted" is loose language; everything is permitted, including things like division by zero that always result in an error. Secondly, in the special case of an xs:NMTOKEN* instance of length 1, the operation will actually succeed.

> I think the same is true for the other list types, xs:ENTITIES(x) is never castable to xs:ENTITIES, and xs:IDREFS(x) is never castable to xs:IDREFS.

It's generally true that if L is a list type whose item type T is a subtype of xs:string, and whose length facets permit a list of length one, then casting an instance of T to L will succeed; and since an instance of T is also an instance of T*, it follows that in this particular case, the cast is idempotent.

Michael Kay
Received on Sunday, 8 May 2016 19:51:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:43:17 UTC