[Bug 11713] [XPath 3.0] Rules for union types

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11713

--- Comment #1 from Michael Kay <mike@saxonica.com> 2011-01-10 15:25:01 UTC ---
Further study of the current XQuery 3.0 draft shows many places where the term
"atomic type" should be generalized since union types are now allowed in many
places where previously atomic types were required.

I think this will be easier if we introduce the definition:

<new>
A *plain* type is an atomic type, or a union type whose base type is
xs:anySimpleType and whose member types are all plain types.

The significance of this definition is that this describes the set of types
that can have atomic values as their instances. </new>

I would suggest putting it in the initial section of 2.5.

Then we need to change "atomic type" (or in some cases "atomic or union type"
to "plain type" in the following places:

2.5 -> "Plain types represent the intersection between the categories of
sequence type and schema type. A plain type, such as xs:integer or my:hatsize,
is both a sequence type and a schema type."

2.5.2 "Instead, if the type annotation of a node is a list type (such as
xs:IDREFS), its typed value is treated as a sequence of atomic values belonging
to the itemType of the list (or where this is a union, to one of the atomic
member types of the union)". 

2.5.3: "Apart from the item type item(), which permits any kind of item, item
types divide into node types (such as element()), plain types (such as
xs:integer) and function types (such as function() as item()*)."

2.5.4.2 "The names of list [was non-atomic] types such as xs:IDREFS are not
accepted in this context, but can often be replaced by an atomic type with an
occurrence indicator, such as xs:IDREF+."

3.1.1. Add "Constructor functions are available for all plain types including
union types. For example if my:dt is a user-defined union type whose member
types are xs:date, xs:time, and xs:dateTime, then the expression
my:dt("2011-01-10") creates an atomic value of type xs:date. The rules follow
XML Schema validation rules for union types: the effect is to choose the first
member type that accepts the given string in its lexical space."

3.1.5.2 "If the expected type is a sequence of a plain type..."; "Each item in
the atomic sequence that is of type xs:untypedAtomic is cast to the expected
atomic type". (But for numeric/URI promotion, keep "atomic type".

3.15.3 "The target type must be a plain type that is in the in-scope schema
types [err:XPST0051]."

3.15.3 Add a new para 4f "casting from a string or untypedAtomic value is
supported if the target type is a plain union type, that is, a union type that
imposes no restrictions other than the restrictions imposed by its member
types. The semantics of casting follow the XSD rules for validation against a
union type; the result of the cast is an atomic value whose type annotation
corresponds to the first atomic member type of the union that has the supplied
value in its lexical space"

3.15.4. "The target type must be a plain type that is in the in-scope schema
types [err:XPST0051]. In addition, the target type cannot be xs:NOTATION or
xs:anyAtomicType [err:XPST0080]."

3.15.5. "For every plain type in the in-scope schema types..."

4.11 "For each user-defined plain type in the schema..."

App C.1, row "function signatures", "atomic" -> "plain"

App C.2, row "function implementations", "atomic" -> "plain"

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 10 January 2011 15:25:04 UTC