- From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
- Date: 16 Jan 2001 08:29:54 +0000
- To: Michael Anderson <michael@research.canon.com.au>
- Cc: Bruno Chatel <bcha@chadocs.com>, xmlschema-dev@w3.org
Michael Anderson <michael@research.canon.com.au> writes: > I must admit that I thought one could do this by extending a > simpleType using the complexContent. Ie similar to the > internationalPrice element in the Primer, except use a > complexContent instead of simpleContent > > <xsd:element name="internationalPrice"> > <xsd:complexType> > <xsd:complexContent> > <xsd:extension base="xsd:decimal"> <!-- Note this line --> > <xsd:sequence> > <xsd:element ref="DateToUseForConversion" /> > </xsd:sequence> > <xsd:attribute name="currency" type="xsd:string"/> > </xsd:extension> > </xsd:complexContent> > </xsd:complexType> > </xsd:element> > > But after the previous emails, I investigated and found in the > Structures spec > > "Schema Representation Constraint: Complex Type Definition > Representation OK 1.1 If the complexContent alternative is chosen, > the type definition resolved to by the normalized value of the base > [attribute] must be a complex type definition;" > > But I can get around this by changing the above base to "myNS:myDecimal" where > myDecimal is a complex type definition > <xsd:complexType name="myDecimal"> > <xsd:simpleContent> > <xsd:extension base="xsd:decimal"/> > </xsd:simpleContent> > </xsd:complexType> > > > This is a fudge around the problem, but it gains you little as > processors are assuming this can't be done anyway. XML Spy > successfully validates an instance with the character sequence in > <internationalPrice> being non-decimal. And XSV is fine with the > schema, but crashes on the instance regardless of whether the > character sequence in <internationalPrice> is decimal or not (so I > assume it doesn't like the dodgey content model created by > extension. > > So I suspect that this is just a loophole in the specs (or I've > missed it somewhere), Yes -- this construction is blocked at a deeper level, see [1]. > > This problem of needing to check ancestors also confuses me with > areas like final. In this case the specification does state that if > the block [attribute] = "extension" then this "prevents further > derivations by extension" [ Section 3.4 Structures ]. But later [ > Section 4.3.3 Structures ], the {final} property is a set > corresponding "to the normalized value of the block [attribute]", > with no mention of ancestor complexTypes. So if I extend a > complexType that had restricted a complexType that had a > block="extension", then is this allowed? No, same reference applies [1]. ht [1] file:///D:/work/xmlschema/structures/structures.xml#coss-ct -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh W3C Fellow 1999--2001, part-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/
Received on Tuesday, 16 January 2001 03:33:49 UTC