Must SOAP-based array types be insufficiently validatable?
The web services industry has chosen, via the WSDL and SOAP specs, to use the W3C XML Schema system by default (others are possible, but rarely used). However, the XML exchanged using these specs sometimes cannot be validated fully by a pure WXS processor that isn't also a SOAP processor. I'm curious to see if anyone knows a way to improve the situation. Here's a typical example (from a public web service): <complexType name="ArrayOfServiceSummary"> <complexContent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType" wsdl:arrayType="tns:ServiceSummary"/> </restriction> </complexContent> </complexType> <complexType name="ServiceSummary"> <sequence> <element name="name" nillable="true" type="xsd:string"/> <element name="id" nillable="true" type="xsd:string"/> <element name="shortDescription" nillable="true" type="xsd:string"/> <element name="wsdlURL" nillable="true" type="xsd:string"/> <element name="publisherID" nillable="true" type="xsd:string"/> </sequence> </complexType> specifies two types, the first supposedly an array of the second. The definition of soapenc:Array is (simplified somewhat) <complexType name="Array" > <sequence> <any namespace="##any" minOccurs="0" maxOccurs="unbounded" processContents="lax"/> </sequence> <attribute name="arrayType" type="string"/> </complexType> So, a SOAP processor can tell that for <Result soap-enc:arrayType="tns:ServiceSummary" xsi:type="tns:ArrayOfServiceSummary"> <i> <name .../> <id .../> ... </i> <i> <name .../> <id .../> ... </i> ... </Result> that the <i> elements are supposed to be of type ServiceSummary. A pure WXS processor cannot tell this -- the xsi:type information is inadequate, and assistance is needed from the arrayType attribute. It thus cannot validate the content of the <i> elements against the desired content model. If the <i> elements are given xsi:type="tns:ServiceSummar" attributes, then their content can be validated, but the whole structure will not be found invalid if a <j> element of some other defined type appears as one of the children of <Result>. I'm working on an application that can prepare user interfaces for displaying and editing instances of schemas found at runtime, with the constraint that wherever possible, the UI must be producible without an instance document (e.g. for preloading and reuse). Handling of indeterminate content such as produced by a schema spec of <any .../> is clearly going to be rather primitive and to be avoided when possible, yet the target of this tool is Web service inputs and results, where the soap-enc:Array definition gets in the way all too often. It appears that what is needed in the definition of soap-enc:Array is that the content is any number of arbitrarily-named elements whose type is the array element type. This appears to require a cooccurrence constraint outside the WXS model, or some kind of preprocessing of generic types (like C++ templates, for example) to generate concrete array types. The undoubtedly clever people who produced the SOAP spec most likely struggled with this problem and did the best they could. Does anyone know of an alternative approach or upcoming improvements to WXS to deal with this? Jeff
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format