From: Kasimier Buchcik <kbuchcik@4commerce.de>

Date: Thu, 28 Oct 2004 11:45:32 +0200

To: <xmlschema-dev@w3.org>

Message-ID: <4180BFBC.30305@4commerce.de>

Date: Thu, 28 Oct 2004 11:45:32 +0200

To: <xmlschema-dev@w3.org>

Message-ID: <4180BFBC.30305@4commerce.de>

Hi, after updating to Xerces-J 2.6.2, I realized that Xerces does follow XSV and MSXML, regarding the comparison of 'anySimpleType' with other simple types. Even if IDC fields resolved to attributes with no type information, i.e. if the attributes were processed by 'skip' wildcards, or 'lax' wildcards with no declarations, Xerces seemed to assume the 'anySimpleType' for the values of those attributes and compared the values the with other values of atomic simple type. Xerces does not work this way anymore; and I now seem to realize why: The simple type definition for 'anySimpleType' states that the type has a variety of _absent_, so even the following dictum for comparison does not apply, since it wants the ancestor type to be _atomic_. "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 " This makes comparison a lot easier :-) Regards, Kasimier Kasimier Buchcik wrote: > Hi, > > I have trouble understanding how 'anySimpleType' is handled if comparing > values. Xerces and XSV seem to differ here. > > Identity-constraint example: > (using Xerces-J 2.5.1, XSV 2.5-2, MSXML 4.0) > > <sequence> > <element name="b" type="anySimpleType"/> > <element name="c" type="float"/> > </sequence> > > <b>1.0</b> > <c>1.0</c> > > with the value of 'c' being a keyref to the key value of 'b'. > > Results: XSV and MSXML do not find the referenced key, Xerces does. > > if both types are 'float': > > Results: All tree validators find the referenced key. > > I cannot find a hint for 'anySimpleType' being not comparable with the > primitive types. The PER for datatypes says: > > "anySimpleType is considered to have an unconstrained lexical space and > a ·value space· consisting of the union of the ·value space·s of all the > ·primitive· datatypes and the set of all lists of all members of the > ·value space·s of all the ·primitive· datatypes." > > Further "4.2.1 equal" says: > > "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 " > > Can someone explain? > > Greetings, > > Kasimier >Received on Thursday, 28 October 2004 09:46:13 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 5 February 2014 07:15:11 UTC
*