Lisa,
Thanks for your reply. This is really only one of the aspects of the restriction issue which I find a little bit unclear. As far as the Spec part 0 is concerned, you do a restriction on a complex type in a schema by copying the exact contents and then making your desired changes, which at the end of the day is a kludge and isn't really set out clearly in part 1 of the spec. For example, conceptually, changing a model group from choice to sequence should also be a valid restriction yet it is a bit unclear whether this is actually allowed.
I actually did some more investigation, and if I define the simple type globally then apply it to the attribute, it works. So the problem here seems to be that the simple type is considered to be locally defined within the attribute, therefore when you do a restriction on the complex type which contains it the (duplicated) simple type has a different scope from the one in the base, therefore it is a "different" base type from the original (because it's scope is different) and therefore an invalid restriction.
However, this does seem a bit inconsistent to me, because the locally defined attributes and elements are available in the derived type for purposes of restriction.
My conclusion is that the whole business of restriction should probably be carefully revisited. Maybe we should just follow the advice of some of the greybeards in this field, which is that if we all agree not to use restrictions, the problem will go away.
Then again, if there was no ambiguity, we'd all be out of a job soon :-)
John
-----Original Message-----
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: 05/06/2001 21:58
Subject: RE: Validation error (restriction)
Hi,
The problem below is interesting. A few of us were discussing this,
and
we're not sure what the spec intended. There are some interesting
variations such as :
- the anonymous type for the attribute in the base is the same as the
anonymous type for the attribute in the restriction, except that
ordering of enumeration values is different.
- the anonymous type for the attribute in the base is the same as the
anonymous type for the attribute in the restriction, except that the
facets are ordered differently.
- etc.
It's not clear what it means for 2 anonymous types to "be the same".
I'll post something to get a clarification from the Schema WG.
Lisa.
------------------------------------------------------------------------
--------
Xerces generates a different error but because of the use of the
following
attribute group within both base and derived type:
<xsd:attributeGroup name="ItemDelivery">
<xsd:attribute name="partNum" type="SKU"/>
<xsd:attribute name="weightKg" type="xsd:decimal"/>
<xsd:attribute name="shipBy" >
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="air"/>
<xsd:enumeration value="sea"/>
<xsd:enumeration value="any"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:attributeGroup>
In this case the error is:
"ComplexType 'ConfirmedItems': derivation-ok-restriction.2.1.2: Type of
attribute 'shipBy' in derivation must be a restriction of type of
attribute
in base."
Again, I find it difficult to see any problem with this restriction
unless
it has to do with the localness of the simple type on that attribute.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
