W3C home > Mailing lists > Public > xmlschema-dev@w3.org > August 2002

RE: Should this schema be invalid?

From: Dare Obasanjo <dareo@microsoft.com>
Date: Thu, 1 Aug 2002 09:07:58 -0700
Message-ID: <8BD7226E07DDFF49AF5EF4030ACE0B7E06621E96@red-msg-06.redmond.corp.microsoft.com>
To: "Jeni Tennison" <jeni@jenitennison.com>, <xmlschema-dev@w3.org>
Cc: "Cliff Schmidt" <cschmidt@microsoft.com>, <www-xml-schema-comments@w3.org>

To clarify, I wasn't asking because we plan to start ignoring the pointless rules in W3C XML Schema. We are completely committed to standards compliance with regards to W3C XML Schema. I just wanted to highlight why the pointlessness rules are bad and should be removed from the REC post haste. 
It is unfortunate that although the W3C XML Schema WG accepted an issue for this[0] none of their proposed resolutions involve getting rid of the confusing, unproductive and completely counter-intuitive rules. Hopefully this situation will be righted in XSD 1.1 
[0] http://www.w3.org/2001/05/xmlschema-rec-comments#pfipointless

	-----Original Message----- 
	From: Jeni Tennison [mailto:jeni@jenitennison.com] 
	Sent: Thu 8/1/2002 3:09 AM 
	To: xmlschema-dev@w3.org; Dare Obasanjo 
	Subject: Re: Should this schema be invalid?

	Hi Dare,
	> Given the rules at
	> http://www.w3.org/TR/xmlschema-1/#cos-particle-restrict it seems the
	> following schema is invalid. Should it be?
	> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	>            elementFormDefault="qualified">
	>   <xs:complexType name="Person" >
	>        <xs:sequence>
	>          <xs:element name="name" type="xs:string" />
	>          <xs:element name="age" type="xs:double" />
	>          <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"  />
	>        </xs:sequence>
	>      </xs:complexType>
	>   <xs:complexType name="WageSlave" >
	>       <xs:complexContent>
	>         <xs:restriction base="Person" >
	>           <xs:sequence>
	>             <xs:element name="name" type="xs:string" />
	>             <xs:element name="age" type="xs:double" />
	>             <xs:sequence>
	>               <xs:element name="ssn" type="xs:string" />
	>               <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded" />
	>             </xs:sequence>
	>           </xs:sequence>
	>         </xs:restriction>
	>       </xs:complexContent>
	>     </xs:complexType>
	> </xs:schema>
	As I see it, the mapping is:
	  (name, age, #other*) -> (name, age, (ssn, #other*))
	The sequence (ssn, #other*) counts as pointless because it has a
	minOccurs and maxOccurs of 1 and it appears in another sequence, so
	the mapping is actually:
	  (name, age, #other*) -> (name, age, ssn, #other*)
	The best functional mapping is then:
	  name    -> name
	  age     -> age
	          -> ssn
	  #other* -> #other*
	which isn't valid because there's no particle in the base type for the
	ssn particle to map on to.
	OK, so that's why the schema is invalid based on the rules. Whether it
	*should* be is a different question. I think that this is a clear
	example of where the rules are highly non-intuitive and don't give the
	"right answer": it's clear to a human that the ssn particle maps to
	the wildcard and that the restriction should be valid. I think that
	the definition of an order-preserving functional mapping needs to be
	changed so that a particle in the base type can map to more than one
	particle in the derived type, as long as the total cardinalities are
	OK. Send along a suggestion to www-xml-schema-comments@w3.org?
	However (just in case you were asking on behalf of the MSXML
	developers), until there's an erratum issued that changes the way in
	which derivations by restriction are assessed, I think validators
	should continue to work by the rules rather than what gives the
	results that the users want; it's bad enough having validators
	behaving differently because of bugs, we don't need them to behave
	differently because of added "features" as well.
	Jeni Tennison
Received on Thursday, 1 August 2002 12:08:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:04 UTC