- From: <bugzilla@jessica.w3.org>
- Date: Mon, 10 Jan 2011 15:25:02 +0000
- To: public-qt-comments@w3.org
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