[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?

  • To: "Jeff Greif" <jgreif@a...>,<xml-dev@l...>
  • Subject: RE: Must SOAP-based array types be insufficiently validatable?
  • From: "Dare Obasanjo" <dareo@m...>
  • Date: Mon, 21 Jul 2003 09:46:55 -0700
  • Thread-index: AcNPoo9Dqvw8knfQQFOSV4ePACMYyAAAy9ah
  • Thread-topic: Must SOAP-based array types be insufficiently validatable?

true types
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.