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 5652 - Constuctors for union types
Summary: Constuctors for union types
Status: CLOSED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows XP
: 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: 2008-04-22 13:29 UTC by Nick Jones
Modified: 2008-04-22 14:07 UTC (History)
0 users

See Also:


Attachments

Description Nick Jones 2008-04-22 13:29:11 UTC
Imagine a schema defining my:sizeType

  <xs:simpleType name="sizeType">
    <xs:union memberType="xs:integer xs:string"/>
  </xs:simpleType>

The various specifications seem to suggest such a constructor exists (5.4) but do not appear to be clear as to what the behaviour of a constructor for such a union type should be.

So for example, should

my:sizeType("123") instance of xs:integer

return true, false, or throw an exception (for the constructor being invalid - if so which?).

Our thoughts are that the behaviour should be the same as during schema validation (so should map to an xs:integer and hence return true), but are unable to find anything definite in the specification to confirm this.
Comment 1 Michael Kay 2008-04-22 13:41:19 UTC
(Personal response)

Section 5.4 starts:

"For every atomic type in the static context that is derived from a primitive type, there is a constructor function..."

A union type is not an atomic type; I think it is quite clear that constructor functions are not defined for list and union types. It would be nice if they were, but currently they are not.
Comment 2 Nick Jones 2008-04-22 14:07:27 UTC
OK. That makes sense.

(We were getting confused as were reading "For every atomic type" as "Any type which is a subtype of xs:anyAtomicType", which the union types are, but clearly isn't what is actually being described in 5.4)