This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When recursively applying the typed value determination rules in section 3.3.1.2 of XDM, a list of union types is not handled properly because the current rules assume each item in the list has associated [member type definition]* properties. For example: <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://example.org/list" xmlns:li="http://example.org/list"> <xs:simpleType name="unionType"> <xs:union memberTypes="xs:integer xs:float"/> </xs:simpleType> <xs:simpleType name="listType"> <xs:list itemType="li:unionType"/> </xs:simpleType> <xs:element name="e" type="li:listType"/> </xs:schema> As is currently defined, when element e is encountered, the last rule in the bulleted list applies to the information item which results from schema assessment - the type T is li:listType, whose {variety} is list. The {item type definition} is li:unionType, so it becomes T for the recursive application of the rules for each space-separated member of the [schema normalized value]. The {variety} of T is now union, and the fourth bullet applies, which relies upon either the [member type definition] or [member type definition anonymous] property, but neither of those properties exists for this information item, so the typed value determination process breaks down. In order for the typed value determination to work for list of union, the PSVI element information item would have to have [member type definition *] properties for each item in the list, which is not the case in "Schema: Structures 1.0", nor in the draft of 1.1. That could be accomplished through a change to XML Schema or by XDM repeating the validation process for the union type on each member of the space-separated list of lexical forms in [schema normalized value] in order to compute the [member type definition *] properties.
Awaiting proposal from Jonathan Robie.
A change proposal prepared by Jonathan Robie and me is at http://lists.w3.org/Archives/Public/www-archive/2006Mar/att-0021/bugs.2768.2790.html__charset_ISO-8859-1 Its effect is to replace the recursive algorithm for finding typed values with a straightforward appeal to the notion of lexical mapping used in XML Schema 1.0.
Created attachment 415 [details] Proposals adopted for bugs 2768 and 2790 These proposals were adopted on 3 April by the XML Query and XSLT Working Groups.
Hi Joanne, I have attached the proposal adopted at today's face to face meetings in response to your bug report - we believe this both fixes the problem and simplifies the description. Jonathan
These changes do not appear in the June 8 draft. I can't explain that, as I clearly recall making the edits and wouldn't have closed the bug if I hadn't.
Additional concerns raised from members mailing list: http://lists.w3.org/Archives/Member/w3c-xsl-query/2006Jun/0017.html For 2768 1. Part of the new text reads "modified by the rules in [Schema Part 1] which make it into a function". I'm not sure which rules you are talking about. Seems to me that all union aspects are handled in part 2. (I may be missing something in part 1. But if I'm having a hard time finding the relevant rules, I'm sure the users/readers will also have difficulties. You may want to have explicit reference to specific sections/constraints.) 2. anySimpleType is handled separated. How about anyAtomicType? In Schema 1.1, similar to anySimpleType, anyAtomicType can also give multiple values for a given lexical input. If Query handles anyAtomicType in the same way, then there is a potential problem of which value to choose; if Query handles anyAtomicType differently, then there is a potential mismatch between Query and schema 1.1. 3. The sentence "the typed value is the result of applying M to the string value" surprised me a bit. Not saying it's wrong, but I didn't expect that values in Query are the same values as in Schema. For example, values of hexBinary and those of base64Binary don't overlap in schema. Is this also true for Query values? And for an atomic type, applying M (schema lexical->value mapping) gives you a single value, where Query would need a sequence. 4. For example, type U is declared as a union of xs:integer|xs:decimal and the lexical value to be validated is "1". According to Schema, this value is then validated as an xs:integer and the name from the members type definition is xs:integer. However, the proposal introduces the concept that lexical mapping should be applied to determine its type-value. In this example, the integer lexical mapping is still applied, but the actual value yields a value from the decimal value space. Thus, the actual type information, xs:integer, is lost. The stuff in Schema on the mapping from the lexical space to the value space for a datatype doesn't give us much to latch onto, but here are some of the things that I think support my understanding of the value space According to section 4.2.1 of Schema Part 2,[1] "for any a and b in the ·value space· if a = b, then a and b cannot be distinguished (i.e., equality is identity)" and "if a datatype T' is ·derived· by ·restriction· from an atomic datatype T then the ·value space· of T' is a subset of the ·value space· of T. Values in the ·value space·s of T and T' can be compared according to the above rules." According to section 2.2,[2] a value space can be defined, among other ways, "by restricting the ·value space· of an already defined datatype" or "as a combination of values from one or more already defined ·value space·(s)" So I read all that as saying that the values in the value space of a type derived by restriction are the same values as the values in the primitive type from which it's derived and that the values in the value space of a union type are the same values in the value spaces of the member types. So, for a union type like xs:int|xs:decimal, I believe that the two points in the lexical space "1" and "1.0" both map to the same value (one) in the value space of the union type, and there is no way of distinguishing the value to which those two points in the lexical space map to - in particular, that there is no type information associated with those values. The stuff in Schema Part 1 about unions only seems to be helpful for unions like xs:gYear|xs:int versus xs:int|xs:gYear where the lexical string "2006" maps to the gYear value 2006 in the first case and to the decimal value 2006 in the second case. 5. "the W3C XML Schema specification defines a function M mapping the lexical representation of a value onto the value itself " Why refer to "function M" when this term is not really defined in Schema (and if so, where in Schema?) . Isn't it more of a "relation" rather than an actual "function"? For 2790 1. (omit) 2. (editorial) Given that you already require the [element/attribute declaration] property, it feels unnecessarily confusing to refer to [type definition anonymous] property later. I would just say "I need [xxx declaration] and [type definition] properties from PSVI." And (for the "otherwise" case) use {name} property of the [type definition] to determine which name to use, instead of consulting [type definition anonymous]. 3. The [element declaration] property may be absent. (For example, an element matching a wildcard but having xsi:type.) You may need to take care of this special case both in the definition of "declared type" (what if [element declaration] is absent) and when "declared type" is used (what if it's absent).
Really actually fixed now. Per the decisions made at the June 2006 f2f.