Re: Mixed content and simpleType

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