RE: What are complexContent restrictions made for ?

Not exactly - That's because the latter form is not constrained by what's
been defined for type personName. 
 
Essentially, when you derive by restriction, you're asserting that the
restricted form is related to the original form; specifically, that it is
the same as, or a "tighter" type than, the original.
 
The restricted form requires that the sequence containing the "surname"
element, and the element itself, are proper restrictions of personName. If,
for example, the surname element did not exist in personName, it would not
be legal in the restriction. Similarly, if the surname were there but its
type in the restriction was not the same as, or a correct derivation of, the
personName's surname element, then the restriction would not be correctly
derived. 
 
Mark
 
Mark Feblowitz                                        
XML Architect
       [t]   617.715.7231                                                 
       [f]   617.495.0188
Frictionless Commerce Incorporated             
       [e]   <mailto:mfeblowitz@frictionless.com>
mfeblowitz@frictionless.com
       [w]  <http://www.frictionless.com/> http://www.frictionless.com
       [m] 400 Technology Square, 9th Floor
             Cambridge, MA 02139 
Open Applications Group Incorporated
       [e]   <mailto:mfeblowitz@openapplications.org>
mfeblowitz@openapplications.org
       [w]  <http://www.openapplications.org/>
http://www.openapplications.org 
 
-----Original Message-----
From: zze-MARCHEGAY Michael stagiaire FTRD/DTL/LAN
[mailto:michael.marchegay@rd.francetelecom.com]
Sent: Wednesday, May 22, 2002 8:13 AM
To: 'Jeni Tennison'
Cc: 'xmlschema-dev@w3.org'
Subject: RE: What are complexContent restrictions made for ?
 
Hi Jeni, 
> 
> 
> Hi Michaël, 
> 
> > I'm trying to understand the interest of complexContent 
> > restrictions, but I don't find in which kind of examples it is 
> > usefull. 
> [snip] 
> > I can't figure out what is the difference between an element which 
> > has type simpleName1 and another which has type simpleName2. 
> > 
> > So are complexContents just syntaxic sugar, used by XML Schema 
> > processing tools or do they have another function? 
> 
> You're absolutely right that in your example, the simpleName1 and 
> simpleName2 complex types have exactly the same content model, so 
> elements of those types are allowed exactly the same content. 
> 
> However, the fact that simpleName1 is derived from personName can be 
> significant. For example, if you were to declare an element with the 
> type personName: 
> 
>   <xsl:element name="name" type="personName" /> 
> 
> then an instance of that element could be assigned the type 
> simpleName1 through the xsi:type attribute: 
> 
>   <name xsi:type="simpleName1">...</name> 
> 
> whereas it couldn't be assigned the type simpleName2. 
> 
So a complexContent is usefull only when used in a type declaration, 
isn't it ? 
If I use one in a "inline" type definition for an element: 
<xs:element> 
  <xs:complexType> 
    <xs:complexContent> 
      <xs:restriction base="personName"> 
        <xs:sequence> 
          <xs:element name="surname"/> 
        </xs:sequence> 
      </xs:restriction> 
    </xs:complexContent> 
  </xs:complexType> 
</xs:element> 
this has **exactly** the same signification as if I write 
<xs:element> 
  <xs:complexType> 
   <xs:sequence> 
     <xs:element name="surname"/> 
   </xs:sequence> 
  </xs:complexType> 
</xs:element> 
isn't it ? 
Thanks. 
> Similarly, an element called simpleName could belong to the name 
> element's substitution group if it had the type simpleName1 (because 
> that's derived from the name element's type) but not if it had the 
> type simpleName2. 
> 
> So within the schema itself, and in terms of what you can do in the 
> instance document, the fact that one of the types is derived from 
> personName and the other isn't can make a significant difference. 
> 
> The other way in which the type hierarchy can help is within 
> processing tools that are aware of the PSVI. XSLT 2.0, for example, is 
> on its way to becoming such a tool, which would mean that you'd be 
> able to match all elements of type personName or simpleName1 with: 
> 
> <xsl:template match="*[. instance of personName]"> 
>   ... 
> </xsl:template> 
> 
> whereas simpleName2 is unrelated to personName. 
> 
> Thus, deriving by restriction is helpful because it enables you to 
> express the commonality between a set of elements, and process them in 
> the same kind of way. 
> 
> Cheers, 
> 
> Jeni 
> 
> --- 
> Jeni Tennison 
> http://www.jenitennison.com/ <http://www.jenitennison.com/>  
-- 
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 
>