- From: Eddie Robertsson <eddie@allette.com.au>
- Date: Wed, 12 Dec 2001 09:28:53 +1100
- To: James Pasley <james.pasley@capeclear.com>
- CC: xmlschema-dev@w3.org
> Typically, when you define arrays you inherit from this definition and > restrict the xs:any's in it to the particular of type in your array, so from > my reading of the inheritance rules, an array of floats should look as > follows: > > <xs:complexType name="ArrayOfFloat"> > <xs:complexContent> > <xs:restriction base="soapenc:Array"> > <xs:sequence> > <xs:element name="item" minOccurs="0" maxOccurs="unbounded" > type="xs:float" /> > </xs:sequence> > <attribute ref="soapenc:arrayType" wsdl:arrayType="xs:float[]"/> > </xs:restriction> > </xs:complexContent> > </xs:complexType> This is not valid. It seems as though you're trying to add a new attribute (soapenc:arrayType) to the derived type and you can never add anything when you derive a new type by restriction, only restrict the content of the base type. If you need to add an attribute you need to first derive the specialized type by restriction and then add the attribute in a new type derived by extension from this type. > However, the WSDL specification ( http://www.w3.org/TR/wsdl ) contains the > following example of an array of floats: > > <complexType name="ArrayOfFloat"> > <complexContent> > <restriction base="soapenc:Array"> > <attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:float[]"/> > </restriction> > </complexContent> > </complexType> > > Now the Schema Primer states the following: > > Notice that types derived by restriction must repeat all > the components of the base type definition that are to be > included in the derived type > > So (and here's the question), is the example from the WSDL specification > incorrect as it neither repeats the xs:any or replaces it with a more > restrictive element. Am I right in thinking that it actually defines an > complex type which can not contain child elements at all? Your correct in that the above type wouldn't contain any child elements but it's also invalid for the same reason I gave above. Cheers, /Eddie
Received on Tuesday, 11 December 2001 17:31:17 UTC