W3C home > Mailing lists > Public > xmlschema-dev@w3.org > January 2001

Re: Mixed content and simpleType

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
Message-ID: <f5blmsbucfx.fsf@cogsci.ed.ac.uk>
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].


[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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:19 GMT