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

RE: Complex content extension

From: Priscilla Walmsley <priscilla@walmsley.com>
Date: Tue, 6 Aug 2002 11:58:28 -0400
To: "'zze-MARCHEGAY Michael stagiaire FTRD/DTL/LAN'" <michael.marchegay@rd.francetelecom.com>, <xmlschema-dev@w3.org>
Message-ID: <000201c23d5b$0988be30$f74988ac@WALMSLEYPH>

Hello Michael,

Yes, as you expect, both the "bar" and "bar-2" types in your schema are
invalid.  The {attribute uses} of a complex type derived by extension is
the union of the attribute declarations in the type definition itself
with the {attribute uses} of the base type.  Since there can be no
duplicate attributes (based on qualified name) in {attribute uses}, it
is an error.

In some cases XSV doesn't find schema errors until you attempt to
validate an instance against the schema.  When you try to validate an
element of type bar or bar-2, XSV gives the appropriate error message:

<schemaError char='3' line='8' phase='instance'
resource='file:/C:/Program Files
/XSV/schema1.xsd'>attempt to extend with an attribute already declared

Hope that helps,

Priscilla Walmsley             priscilla@walmsley.com
Author, Definitive XML Schema     (Prentice Hall PTR)

> -----Original Message-----
> From: xmlschema-dev-request@w3.org 
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of 
> zze-MARCHEGAY Michael stagiaire FTRD/DTL/LAN
> Sent: Tuesday, August 06, 2002 5:35 AM
> To: xmlschema-dev@w3.org
> Subject: Complex content extension
> Hi all,
> I would like to have clarifications about complex content extension 
> attributes. 
> I read in the book "Definitive XML Schema" that complex 
> content extensions
> "cannot modify or remove existing attributes". I found the 
> same kind of 
> statement in another book: "Professional XML Schemas".
> I tried to find the paragraph that explains this behaviour in the 
> Recomendation, but I haven't managed to get it. However, I 
> found a paragraph
> that introduced doubt about my understanding of those complex content 
> extensions:
> 3.4.6 Constraints on Complex Type Definition Schema Components
> [...]
> Schema Component Constraint: Derivation Valid (Extension) 
> If the {derivation method} is extension, the appropriate case 
> among the following must be true:
> 1 If the {base type definition} is a complex type definition, 
> then all of the following must be true:
> 1.1 The {final} of the {base type definition} must not 
> contain extension. 
> 1.2 Its {attribute uses} must be a subset of the {attribute 
> uses} of the complex type definition itself, that is, for 
> every attribute use in the {attribute uses} of the {base type 
> definition}, there must be an attribute use in the {attribute 
> uses} of the complex type definition itself whose {attribute 
> declaration} has the same {name}, {target namespace} and 
> {type definition} as its attribute declaration.
> [...]
> Using the book and the Recommandation text, I deduced that 
> the following 
> schema should be invalid but but according to SQC and XSV it is not.
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>   <xsd:complexType name="foo">
>     <xsd:attribute name="a" type="xsd:boolean" use="optional"/>
>   </xsd:complexType>
>   <xsd:complexType name="bar">
>     <xsd:complexContent>
>       <xsd:extension base="foo">
>         <xsd:attribute name="a" type="xsd:boolean" use="required"/>
>       </xsd:extension>
>     </xsd:complexContent>
>   </xsd:complexType>
>   <xsd:complexType name="bar-2">
>     <xsd:complexContent>
>       <xsd:extension base="foo">
>         <xsd:attribute name="a" type="xsd:boolean" use="prohibited"/>
>       </xsd:extension>
>     </xsd:complexContent>
>   </xsd:complexType>
> </xsd:schema>
> Can you help me to understand these complex content extension stuff?
> Thanks,
> Michael.
> --
> MichaŽl Marchegay, Stagiaire France Telecom R&D du 11/02/2002 
> au 26/07/2002
> Sous la responsabilitť d'Olivier Dubuisson
> DTL/TAL - 22307 Lannion Cedex - France
Received on Tuesday, 6 August 2002 12:00:58 UTC

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