LC-56: restriction awkward

I can't say that I'm satisfied with the resolution to LC-56 (http://www.w3.org/2000/05/12-xmlschema-lcissues.xml#restriction-awkward).

Basically, I said two things: the current approach appeared complex 
to implement and was minimally documented.  If the current approach, 
which generally is acknowledged as awkward, is going to be maintained, 
then it at least deserves more than a sentence or two in the prose of 
the Primer and Structures document.

Definitely, the current approach works well with attributes since 
they can be readily addressed by name.  

I agree with the comment that there is no obvious elegant solution 
to uniquely address a particular particle of a very complicated 
content model for the base complexType.  That begs the question 
is there an reasonable alternative that would accomplish most 
or all of the use cases without needing to address the particles in 
the base complexType.

Basically, what I'm suggesting is that the content model in the 
restriction be executed in parallel to the base complexType's content 
model.  Only an element that satisfies both the base and restriction
content model would be valid.  Only the base content model would be
used to determine the behavior of any type-aware DOM.


Use case 1: Prohibiting an specific element that optionally appeared
in the base type.  In this example, a shippingWeight element was
allowed in the content model of a deep ancestor (pretend it was about the
twentieth particle in the content model).  This particular item, concreteFoundation,
is not shippable so the schema author wants to prohibit the appearance
of the shippingWeight element.

<complexType name="concreteFoundation" base="structureBase" derivedBy="restriction">
	<any>
		<!--  qualified would be the default, but shown here  -->
		<exclude qname="shippingWeight" qualified="true"/>
	</any>
</complexType>
	
This uses an enhanced form of the <any> particle that allows the exclusion
of specific elements.  qname was used instead of name since you may want to
prohibit a specific element from another namespace that appeared in a
base complexType defined in an imported schema.  ref was not used since
it does not block a specific top level element, but also blocks any
local element that has the same namespace identifier and local name.  It would
probably good to also have an explicit equivClass attribute on exclude 
when the intention is to exclude all members of an equivClass, not all
elements with the same local name and namespace.

Use Case 2: Requiring a restricting the multiplicity of an element.

Say if concreteType was an optional element in the base complex type.

<complexType name="concreteFoundation" base="structureBase" derivedBy="restriction">
	<sequence>
		<any>
			<exclude qname="concreteType"/>
		</any>
		<element ref="concreteType" minOccurs="1" maxOccurs="1"/>
		<any/>
	</sequence>
</complexType>

Use Case 3: Prohibiting all content

Approach 1: (I still don't like the content attribute)
<complexType name="concreteFoundation" base="structureBase" 
	derivedBy="restriction" content="empty">
	<attribute name="name" use="required"/>
</complexType>

Approach 2: (lack of particle is equivalent to restriction to empty content model)
<complexType name="concreteFoundation" base="structureBase" derivedBy="restriction">
	<attribute name="name" use="required"/>
</complexType>

Approach 3: (lack of particle means no restriction of base content (probably best)
<complexType name="concreteFoundation" base="structureBase" derivedBy="restriction">
	<attribute name="name" use="required"/>
	<sequence/>
</complexType>

Use Case 4: No restriction of content model

Approach 1 & 2:
<complexType name="concreteFoundation" base="structureBase" derivedBy="restriction">
	<attribute name="name" use="required"/>
	<any/>
<complexType>

Approach 3:

<complexType name="concreteFoundation" base="structureBase" derivedBy="restriction">
	<attribute name="name" use="required"/>
<complexType>


It should not be required for the processor to try to determine if the restriction
produce a content model that cannot be satisfied.

This would seem to provide a mechanism to achieve the all goals of restriction 
of content models types with much less complexity to both the implementer and user.

Received on Thursday, 20 July 2000 15:21:42 UTC