FW: constraining an element to be either simple or complex conten t

This issue was raised in June on the schema-ig list.  
Originally I thought I'd identified a bug in XML Spy.  
The discussion sucked in Alexander Falk and Henry Thompson 
and ended up in the same place you identifed:

=============
Alexander Falk said:  

By specifying a complexType with a simpleContent included, you are entering
into the "Complex Type Definition with simple content Schema Component"
scenario, which is described in detail in the XML Schema Rec:

        http://www.w3.org/TR/xmlschema-1/#Complex_Type_Definition_details 

In there, you'll find this definition of how the content type of such a
construct is to be interpreted: 

1 if the type definition ·resolved· to by the ·actual value· of the base
[attribute] is a complex type definition (whose own {content type} must be a
simple type definition, see below) and the <restriction> alternative is
chosen, then starting from either 

1.1 the simple type definition corresponding to the <simpleType> among the
[children] of <restriction> if there is one; 

1.2 otherwise (<restriction> has no <simpleType> among its [children]), the
simple type definition which is the {content type} of the type definition
·resolved· to by the ·actual value· of the base [attribute] 

a simple type definition which restricts that simple type definition with a
set of facet components corresponding to the appropriate element information
items among the <restriction>'s [children] (i.e. those which specify facets,
if any), as defined in Simple Type Restriction (Facets) (§3.14.3);

2 otherwise if the type definition ·resolved· to by the ·actual value· of
the base [attribute] is a complex type definition (whose own {content type}
must be a simple type definition, see below) and the <extension> alternative
is chosen, then the {content type} of that complex type definition;

3 otherwise (the type definition ·resolved· to by the ·actual value· of the
base [attribute] is a simple type definition and the <extension> alternative
is chosen), then that simple type definition.  

In your example, we are covered by case 1, because the base is a complexType
and you are using a restriction. However, it clearly says "whose own
{content type} must be a simple type definition" and this is not the case
for your AbstractQuantityType, which uses a mixed="true" content model and
that is per definition always a complex content.

=================
and Henry Thompson responded:

This is a known bug in the REC -- there's a contradiction between the
section you quote, restated in Schema Representation Constraint:
Complex Type Definition Representation OK [1]
and clause 5.1.2 of Schema Component Constraint: Derivation Valid
(Restriction, Complex) [2]:

  5.1 If the {content type} of the complex type definition is a simple
  type definition, then one of the following must be true:

    5.1.1 The {content type} of the {base type definition} must be a
    simple type definition of which the {content type} is a ·valid
    restriction· as defined in Derivation Valid (Restriction, Simple)
    (§3.14.6).

    5.1.2 The {base type definition} must be mixed and have a particle
    which is ·emptiable· as defined in Particle Emptiable (§3.9.6).

In the face of this contradiction, implementations are free to go
either way.  In due course the WG will have to resolve the
contradiction.  I will argue that 5.1.2 should stay, and a clause
added to the mapping and XML representation sections to accommodate
this.  It seems inconsistent to

 a) allow mixed content elements to have defaults;
 b) allow mixed content types to be restricted to empty;
 c) *not* allow mixed content types to be restricted to text-only with 
    a type.

[1] http://www.w3.org/TR/xmlschema-1/#src-ct
[2] http://www.w3.org/TR/xmlschema-1/#coss-ct

_____
Simon.Cox@csiro.au  CSIRO Exploration & Mining
26 Dick Perry Avenue, Kensington WA 6151
PO Box 1130, Bentley WA 6102  AUSTRALIA
T: +61 (8) 6436 8639  F: +61 (8) 6436 8555  C: +61 (4) 0330 2672
http://www.csiro.au/page.asp?type=resume&id=CoxSimon

-----Original Message-----
From: Priscilla Walmsley [mailto:priscilla@walmsley.com]
Sent: Saturday, 20 October 2001 1:02 AM
To: 'Jeni Tennison'; 'Priscilla Walmsley'
Cc: xmlschema-dev@w3.org
Subject: RE: constraining an element to be either simple or complex
content


Hi Jeni,

That's a good point, and I think we may have uncovered a contradiction in
the Rec.  The section I was looking at is Derivation Valid (Restriction,
Complex) in clause 5:

5.1 If the {content type} of the complex type definition is a simple type
definition, then one of the following must be true:
5.1.1 The {content type} of the {base type definition} must be a simple type
definition of which the {content type} is a ·valid restriction· as defined
in Derivation Valid (Restriction, Simple) (§3.14.6).
5.1.2 The {base type definition} must be mixed and have a particle which is
·emptiable· as defined in Particle Emptiable (§3.9.6).

Unless maybe I should have used "complexContent"?  I will investigate
further....

Priscilla
-----------------------------------------------------------
Priscilla Walmsley                   priscilla@walmsley.com
Vitria Technology                     http://www.vitria.com
Author, Definitive XML Schema    (Prentice Hall, Dec. 2001)
-----------------------------------------------------------

> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com]
> Sent: Friday, October 19, 2001 12:44 PM
> To: Priscilla Walmsley
> Cc: xmlschema-dev@w3.org
> Subject: Re: constraining an element to be either simple or complex
> content
>
>
> Hi Priscilla,
>
> > You can't extend simple content to create complex content, but you
> > _can_ restrict mixed complex content to create simple content. In
> > this situation, you would define the types as:
> >
> > <xs:complexType name="baseType" mixed="true" abstract="true">
> >   <xs:sequence>
> >     <xs:any minOccurs="0" maxOccurs="unbounded"/>
> >   </xs:sequence>
> > </xs:complexType>
> >
> > <xs:complexType name="simpleType">
> >   <xs:simpleContent>
> >     <xs:restriction base="baseType">
> >       <xs:simpleType>
> >         <xs:restriction base="xs:integer"/>
> >       </xs:simpleType>
> >     </xs:restriction>
> >   </xs:simpleContent>
> > </xs:complexType>
>
> Wow, that is obscure! It works in XSV, but I'm confused about why,
> because Clause 2 of the Complex Type Definition Representation OK
> Schema Representation Constraint says:
>
>   2 If the <simpleContent> alternative is chosen, the type
>     definition ·resolved· to by the ·actual value· of the base
>     [attribute] must be either a complex type definition whose
>     {content type} is a simple type definition or, only if the
>     <extension> alternative is also chosen, a simple type definition;
>
> but the base attribute in the definition of the 'simpleType' type is a
> complex type definition whose {content type} is a *complex* type
> definition, isn't it?
>
> Or am I reading it wrong?
>
> Cheers,
>
> Jeni
>
> ---
> Jeni Tennison
> http://www.jenitennison.com/
>
>

Received on Monday, 22 October 2001 04:46:58 UTC