- From: Pete Cordell <petexmldev@tech-know-ware.com>
- Date: Wed, 24 Jan 2007 18:12:53 -0000
- To: "Michael Kay" <mike@saxonica.com>, "'Henry S. Thompson'" <ht@inf.ed.ac.uk>
- Cc: <xmlschema-dev@w3.org>
Original Message From: "Michael Kay" <mike@saxonica.com> > > This situation can't occur with elements because UPA prevents an element > particle overlapping with an element wildcard particle. There's no > corresponding rule for attributes: the explicit attribute wins over the > attribute wildcard. It's not clear why the rules for elements/attributes > here are asymmetric. I haven't finished reading the proposed XSD 1.1 yet (don't spoil the ending for me!), but presumably this will change under XSD 1.1 when the UPA is relaxed. Then elements with maxOccurs = 0 will be treated as nothing rather than prohibited in much the same way as attributes with use='prohibited' and the same situation will arise. > Rather than making this case an error (an invalid schema), it would seem > more helpful to define the rules so that use="prohibited" means what it > says: an attribute of this name is prohibited, despite the presence of a > wildcard that would otherwise permit it. Makes sense to me. Pete. > Michael Kay > http://www.saxonica.com/ > > >> -----Original Message----- >> From: xmlschema-dev-request@w3.org >> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Henry S. Thompson >> Sent: 24 January 2007 13:49 >> To: srinivasarao vegunta >> Cc: xmlschema-dev@w3.org >> Subject: Re: Interaction of explicit attributes and wildcards >> >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> [Please _don't_ use HTML-format mail to public lists -- not >> all of us are using Outlook!] >> >> srinivasarao vegunta writes: >> >> According to several schema processors, (Saxon, Xerces, MS >> .NET), the >> following instance: >> >> <e att1="banana"/> >> >> is valid against the following schema: >> >> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" >> >> elementFormDefault="qualified" >> attributeFormDefault="unqualified"> >> <xs:complexType name="B"> >> >> <xs:sequence/> >> >> <xs:attribute name="att1" use="optional" type="xs:decimal"/> >> >> <xs:anyAttribute namespace="##local" >> >> processContents="skip"/> >> >> </xs:complexType> >> >> <xs:complexType name="R"> >> >> <xs:complexContent> >> >> <xs:restriction base="B"> >> >> <xs:attribute name="att1" use="prohibited"/> >> >> <xs:anyAttribute namespace="##local" >> >> processContents="skip"/> >> >> </xs:restriction> >> >> </xs:complexContent> >> >> </xs:complexType> >> >> <xs:element name="e" type="R"/> >> >> </xs:schema> >> >> But change the element declaration to <xs:element name="e" >> type="B"/>, and >> validation fails, saying that "banana" is not a valid >> xs:decimal (the same >> set of schema processors agree on this). >> >> Surely the element cannot be a valid instance of R unless it >> is also a valid >> instance of B? >> >> >> You have hit on one of the areas where the Schema REC fails >> to live up to its own promise that restrictions accept >> subsets of their base. >> >> The behaviour you describe is conformant, it follows all the >> explicit rules in the spec. for checking valid restrictions. >> It's just that those rules aren't quite 'right'. >> >> The XML Schema WG expects to fix this problem in v1.1. >> >> ht >> - -- >> Henry S. Thompson, HCRC Language Technology Group, >> University of Edinburgh >> Half-time member of W3C Team >> 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) >> 131 650-4440 >> Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk >> URL: http://www.ltg.ed.ac.uk/~ht/ [mail >> really from me _always_ has this .sig -- mail without it is >> forged spam] -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.2.6 (GNU/Linux) >> >> iD8DBQFFt2PbkjnJixAXWBoRArzHAJsFzcU5+hgsZ61Wsiq7Ue2dTu8n4QCeJKNC >> FFyL2hvq4zjr4bzRiZuf31I= >> =pVkY >> -----END PGP SIGNATURE----- -- ============================================= Pete Cordell Tech-Know-Ware Ltd for XML to C++ data binding visit http://www.tech-know-ware.com/lmx (or http://www.xml2cpp.com) =============================================
Received on Wednesday, 24 January 2007 18:13:16 UTC