[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Must SOAP-based array types be insufficiently validatable?
This problem could be solved by the ability to create typed wildcards in W3C XML Schema. Of course, this could also be solved by avoiding SOAP section 5 encoding as well. PS: I also suspect you can solve this simply by applying derivation by restriction properly instead of the hacky way that is shown below. Relying on xsi:type is a bad idea and something that should be discouraged. It would seem to make more sense if "ServiceSummary" was an element with an anonymous complex type unless it is a primary goal that derived types (either by restriction or extension) are acceptable where a "ServiceSummary" type is expected which seems like an unhelathy practice in the general case. ________________________________ From: Jeff Greif [mailto:jgreif@a...] Sent: Mon 7/21/2003 9:09 AM To: xml-dev@l... Subject: 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[352]" 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 ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://lists.xml.org/ob/adm.pl>
|
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
|