Content Type of complex type must not be empty?

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 Saturday, 27 November 2004 23:52:43 UTC