From: Stefan Wachter <Stefan.Wachter@gmx.de>

Date: Wed, 30 Oct 2002 09:58:20 +0100 (MET)

To: "Dare Obasanjo" <dareo@microsoft.com>; xmlschema-dev@w3.org

Message-ID: <21043.1035968300@www16.gmx.net>

Date: Wed, 30 Oct 2002 09:58:20 +0100 (MET)

To: "Dare Obasanjo" <dareo@microsoft.com>; xmlschema-dev@w3.org

Message-ID: <21043.1035968300@www16.gmx.net>

I also read the definition of equality in the specification carefully. Unfortunately it says nothing about the case where a type is a restriction: > Note that a consequence of the above is that, given *value space* A and > *value space* B where A and B are not related by *restriction* or > *union*, for every pair of values a from A and b from B, a != b." Yet, if the above conclusion can also be read from right to left (neglecting unions), for every a from A and b from B: a != b => A and B are not related by restriction is equivalent to A and B are related by restriction => there exists an a from A and b from B: a = b Comming back to the example: I don't think that the types "b" and "r" should be called equal (because one type is a restriction of the other) but there must be values of type "r" that are equal to values of type "b" because restriction is defined to restrict the value space, i.e. the value space of a restricted type is a subspace of the value space of its base type. Applying this principle to the original problem implies that there are values of type xsd:decimal that are equal to values of type xsd:anyType. --Stefan PS: I think that the type system of XML-Schema should behave like type systems in programming languages where values of primitive types are considered equal even if they have not the same type: (byte)5 = (long)5 > The definition of equality is in the W3C XML Schema Datatypes > recommendation at http://www.w3.org/TR/xmlschema-2/#equal and states > > "* for any a and b in the *value space*, either a is equal to b, denoted > a = b, or a is not equal to b, denoted a != b > * there is no pair a and b from the *value space* such that both a = b > and a != b > * for all a in the *value space*, a = a > * for any a and b in the *value space*, a = b if and only if b = a > * for any a, b and c in the *value space*, if a = b and b = c, then > a = > c > * for any a and b in the *value space* if a = b, then a and b cannot > be > distinguished (i.e., equality is identity) > > Note that a consequence of the above is that, given *value space* A and > *value space* B where A and B are not related by *restriction* or > *union*, for every pair of values a from A and b from B, a != b." > > The last sentence seems to imply that in your example both types are > equal. > > -- > PITHY WORDS OF WISDOM > When in doubt, ignore it. > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > > > > > > -----Original Message----- > > From: Stefan Wachter [mailto:Stefan.Wachter@gmx.de] > > Sent: Tuesday, October 29, 2002 11:20 AM > > To: xmlschema-dev@w3.org > > > > > > Hi all. > > > > The current discussion on types states that > > > > <isbn xsi:type="xsd:decimal">1234.0</isbn> > > <isbn>1234</isbn> > > > > are not equal because they have different types. > > > > If I define two new simple types > > > > <simpleType name="b"> > > <restriction base="xsd:decimal"> > > <enumeration value="123"/> > > </restriction> > > </simpleType> > > > > and > > > > <simpleType name="r"> > > <restriction base="b"/> > > </simpleType> > > > > then the values > > > > <v1 xsi:type="b">123</v1> > > <v2 xsi:type="r">123</v2> > > > > are also not equal because they have different types, right? > > But both values are valid because they are equal to the > > enumerated value. Therefore both values must be equal! > > > > Where is my mistake? > > > > --Stefan > > > > PS: Until now I assumed that simple values are equal iff > > > > 1. they have the same type or the type of one value is a base > > type of the type of the other value and 2. the values are > > equal with respect to their common type or the base type, > > respectively. > > > > >Received on Wednesday, 30 October 2002 03:58:53 UTC

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