From: <sandygao@ca.ibm.com>

Date: Thu, 25 Apr 2002 11:37:09 -0400

To: "Ashok Malhotra" <ashokma@microsoft.com>

Cc: www-xml-schema-comments@w3.org

Message-ID: <OF740C2B83.04F41778-ON85256BA6.004E22E1@torolab.ibm.com>

Date: Thu, 25 Apr 2002 11:37:09 -0400

To: "Ashok Malhotra" <ashokma@microsoft.com>

Cc: www-xml-schema-comments@w3.org

Message-ID: <OF740C2B83.04F41778-ON85256BA6.004E22E1@torolab.ibm.com>

Hi Ashok. Thanks for your reply. > [AM] I don't know how to tell if two value spaces are subsets of some primitive value space. I only know such a relation exists for types derived by restriction. There are 19 primitive types. If hexBinary and base64Binary share the same value space (this seems to be true according to how their value spaces are defined); QName and NOTATION share the same value space; float has a value space that's a subset of that of double, then we have 16 primitive value spaces. We need another one for list values: list of a union of the other 16 primitive value spaces. So we have totally 17. Each value space represents its values in a distinct way, that is, a different Java class if it's represented in Java. Now given two values, no matter how they were generated, by which types, their equality can be checked independent of the types: The two values are equal if and only if they both belong to the same primitive value space (call it PVS) (that is, both are list values, or both are non-list values, and belong to the same non-list primitive value space), and the appropriate case among the following is true: 1.1 the PVS is not the list value space, and the two values represent the same value in this PVS. 1.2 the PVS is a the list value space, and the two values have the same length, and all their item values at matching index are equal. IMO, users would prefer this over type-based equality, because it allows float(1.0) == double(1.0); int(1) == unsignedInt(1); etc. There is one point worth thinking about though: what's the value space of "anySimpleType"? Places of the spec indicate that it's the union of the value spaces of all primitive types, but I always have difficulties accepting it. The reason is that anySimpleType doesn't have the ability to understand a lexical representation, and convert it to an actual value. For example, if we have the lexical value "1.0", different primitive types know whether it's valid, and how to interpret it, but anySimpleType doesn't. So it's value space should really be an empty set (or at most the value space of "string" type, but I don't like it). This seems to violate the "derivation constraints value space" rule. But since we already made some exceptions for primitive types deriving from anySimpleType, it won't hurt to have one more. BTW, it'd be appreciated if someone could answer my other questions: 1. what are the values of totalDigits/fractionDigits for decimal "0.00"? 2. Whether international decimal characters that are out of the range #x30~#x39 (#x660, for example) are allowed in date time types? Thanks, Sandy Gao Software Developer, IBM Canada (1-905) 413-3255 sandygao@ca.ibm.com "Ashok Malhotra" To: Sandy Gao/Toronto/IBM@IBMCA, <www-xml-schema-comments@w3.org> <ashokma@micro cc: soft.com> Subject: RE: Questions about "equal" fundamental facet 04/24/2002 04:59 PM Please respond to "Ashok Malhotra" Sandy, see comments inline. All the best, Ashok =========================================================== -----Original Message----- From: sandygao@ca.ibm.com [mailto:sandygao@ca.ibm.com] Sent: Wednesday, April 24, 2002 11:43 AM To: www-xml-schema-comments@w3.org Subject: Questions about "equal" fundamental facet 1. Is it defined on "value spaces", or "types"? In 4.2.1 of the datatype spec: "Every ·value space· supports the notion of equality, ...". So it seems that "equal" is defined on "value spaces". Does this imply that two (unconnected) types (with the same value space) can have equal values? For example, hexBinary and base64Binary have the same value space ("the set of finite-length sequences of binary octets"). hexBinary value "00" and base64Binary value "AA==" both represent one byte of value "0". Then are the two values equal? I would say they are equal, if "equal" is defined on value spaces. But 3.11.1 of the structure spec says "Values of differing type can only be equal if one type is derived from the other, and the value is in the value space of both". Here it seems to indicate something different. Is this a contradiction? [AM] Equality is defined on values. The values must be in the same value space. Since derivation by restriction merely narrows the value space a value of a base type may equal a value of a derived (by restriction) type. 2. Does the types have to be related by ·restriction· or ·union·? If type A restricts "integer" by setting "minInclusive=0", and B restricts "integer" by setting "maxInclusive=10". Now A and B are not related by restriction or union. But I still expect value "5" from both types (values spaces) to be equal. (If they have to be related by ·restriction· or ·union·, doesn't 3.11.1 of the structure spec need to be modified to be more strict, instead of simply saying "derived from"?) [AM] By restriction. My take on these 2 questions: 1. "equal" should be defined on value spaces, because equal values are equal, no matter how they were lexically represented. [AM] Correct! 2. Types used to generate equal (actual) values don't need to be related. As long as there exist a (primitive) value space to which both values belong, and the two values are equal in that value space, then they are equal. This means hexBinary and base64Binary can generate equal values, so can QName and NOTATION. Further on this, maybe the value space of "float" should (or already is) be a subset of that of "double", so that these types can generate equal values. [AM] I don't know how to tell if two value spaces are subsets of some primitive value space. I only know such a relation exists for types derived by restriction. Thanks, Sandy Gao Software Developer, IBM Canada (1-905) 413-3255 sandygao@ca.ibm.comReceived on Thursday, 25 April 2002 11:37:48 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 14:50:00 UTC
*