Re: Content Type of complex type must not be empty?

Hi Jack,

The error message you quote seems to refer to Schema Representation 
Constraint: Complex Type Definition Representation OK 2.1.2
http://www.w3.org/TR/xmlschema-1/#cl-esc

but, your schema satisfies 2.1.1 so it should be OK:

2.1 The type definition ·resolved· to by the ·actual value· of the base 
[attribute] must be *one* of the following:
2.1.1 a complex type definition whose {content type} is a simple type 
definition;
2.1.2 only if the <restriction> alternative is also chosen, a complex 
type definition whose {content type} is mixed and a particle which is 
·emptiable·, as defined in Particle Emptiable (§3.9.6);
2.1.3 only if the <extension> alternative is also chosen, a simple type 
definition.

The actual value of the base for ProductNameType is NameType whose 
content type is NameBaseType which is a simple type definition:

<xs:complexType name="NameType">
   <xs:simpleContent>
     <xs:extension base="c:NameBaseType">
       <xs:attribute ref="xml:lang" use="required"/>
     </xs:extension>
   </xs:simpleContent>
</xs:complexType>


<xs:simpleType name="NameBaseType">
   <xs:restriction base="xs:string">
     <xs:maxLength value="255"/>
   </xs:restriction>
</xs:simpleType>

The {content type} for NameType is found applying the following rule:

http://www.w3.org/TR/xmlschema-1/#declare-type
Complex Type Definition with simple content Schema Component
{content type} 4

(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.

Hope that helps,
George
---------------------------------------------------------------------
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com


Jack Lindsey wrote:
> 
> The latest version of some Austrian graphical IDE has suddenly started 
> to object to my schema, while oXygen still thinks its OK.  I thought 
> this would be the place to get an authoritative call on the issue. The 
> error says:
> 
> "The Content Type of complexType 'c:ProductNameType' must not be 'empty' 
> because the Content Type of complexType 'c:NameType is neither 'empty' 
> nor is its 'minOccurs' value '0'."
> 
> Is this valid or is it trying to tell me I can't derive a type by 
> restriction just to get a new type name?  I must explicitly add a 
> further restriction?  Or what?
> 
> Here is a realistic simulation which validates in my version of said IDE:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema targetNamespace="http://space" xmlns:c="http://space" 
> xmlns:xs="http://www.w3.org/2001/XMLSchema">
>     <xs:import namespace="http://www.w3.org/XML/1998/namespace" 
> schemaLocation="http://www.w3.org/2001/xml.xsd"/>
>     <xs:element name="Product" type="c:ProductType" />
>     <xs:complexType name="ProductType">
>         <xs:sequence>
>             <xs:element ref="c:ProductName" minOccurs="0" 
> maxOccurs="unbounded"/>
>         </xs:sequence>
>     </xs:complexType>
>     <xs:element name="ProductName" type="c:ProductNameType" />
>     <xs:complexType name="ProductNameType">
>         <xs:simpleContent>
>             <xs:restriction base="c:NameType"/>
>         </xs:simpleContent>
>     </xs:complexType>
>     <xs:complexType name="NameType">
>         <xs:simpleContent>
>             <xs:extension base="c:NameBaseType">
>                 <xs:attribute ref="xml:lang" use="required"/>
>             </xs:extension>
>         </xs:simpleContent>
>     </xs:complexType>
>     <xs:simpleType name="NameBaseType">
>         <xs:restriction base="xs:string">
>             <xs:maxLength value="255"/>
>         </xs:restriction>
>     </xs:simpleType>
> </xs:schema>
> 
> 
> You may be wondering why the 3-step type derivation?
> 
> The first objective was to create a set of standard datatypes that would 
> be consistently used across the whole model, e.g. a NameType of 255 
> characters, a restriction of xs:string.
> 
> The second was to permit the identification of the language used for 
> elements containing translatable text.  This meant the addition of the 
> xml:lang attribute, an extension.  However xsd does not permit both 
> extension and restriction in a single step, hence the creation of 
> BaseNameType, which in this case is an intermediate byproduct with no 
> subsequent function, except to confuse those who follow.  Any chance of 
> a syntax change to avoid this in future releases?
> 
> The third objective was to ensure an audit trail back to the original 
> element, e.g. by giving ProductName a type of ProductNameType which 
> vocabulary extenders could use for derivation by restriction to 
> constrain its original facets, such as length or specific enumerations.
> 
> However, we are seeing now how such restrictions can severely dilute the 
> benefits of a using xsd for a standard xml vocabulary.  As a result, we 
> are investigating complementing xsd with Schematron as an alternative 
> approach.
> 
> I believe it was Jeni, some months ago, who mentioned that a debate on 
> validation strategies was going on in a related forum?  Could someone 
> point me in the right direction, or other good directions, please?
> 
> Cheers Jack
> 
> _________________________________________________________________
> Powerful Parental Controls Let your child discover the best the Internet 
> has to offer.  
> http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines 
>  Start enjoying all the benefits of MSN. Premium right now and get the 
> first two months FREE*.
>

Received on Monday, 29 November 2004 09:29:16 UTC