[Bug 2790] Instance of with union type results in surprising results

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


joannet@ca.ibm.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




------- Comment #6 from joannet@ca.ibm.com  2006-06-23 12:49 -------
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).

Received on Friday, 23 June 2006 12:49:31 UTC