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 2768 - [XDM] constructing list of union types from PSVI
Summary: [XDM] constructing list of union types from PSVI
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Data Model 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Norman Walsh
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2006-01-25 14:06 UTC by Joanne Tong
Modified: 2006-06-29 18:56 UTC (History)
0 users

See Also:

Proposals adopted for bugs 2768 and 2790 (18.47 KB, text/html)
2006-04-03 17:32 UTC, Jonathan Robie

Description Joanne Tong 2006-01-25 14:06:51 UTC
When recursively applying the typed value determination rules in section 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=""
  <xs:simpleType name="unionType">
    <xs:union memberTypes="xs:integer xs:float"/>

  <xs:simpleType name="listType">
    <xs:list itemType="li:unionType"/>

  <xs:element name="e" type="li:listType"/>

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 *] 
Comment 1 Norman Walsh 2006-03-14 16:09:08 UTC
Awaiting proposal from Jonathan Robie.
Comment 2 C. M. Sperberg-McQueen 2006-03-20 18:57:06 UTC
A change proposal prepared by Jonathan Robie and me is at

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.
Comment 3 Jonathan Robie 2006-04-03 17:32:40 UTC
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.
Comment 4 Jonathan Robie 2006-04-03 17:35:29 UTC
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.

Comment 5 Norman Walsh 2006-06-21 14:14:12 UTC
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.
Comment 6 Joanne Tong 2006-06-23 12:47:38 UTC
Additional concerns raised from members mailing list:

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 

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 

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 

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).
Comment 7 Norman Walsh 2006-06-29 18:56:23 UTC
Really actually fixed now. Per the decisions made at the June 2006 f2f.