[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: "Dare Obasanjo" <dareo@m...>,<xml-dev@l...>
• Subject: Re: Must SOAP-based array types be insufficiently validatable?
• From: "Jeff Greif" <jgreif@a...>
• Date: Mon, 21 Jul 2003 10:34:34 -0700
• References: <830178CE7378FC40BC6F1DDADCFDD1D1173AF0@R...>

Thanks for the helpful comments.  My application encounters various web
services completely outside my control, specified using various mechanisms
including the one under discussion.  I'm trying to figure out how to deal
with these in some automatic way, living with what is found 'in the wild'.
What seems to be looming now is to deal with the case in question by using
the knowledge a SOAP processor would have and possibly transforming the WSDL
file and its contained or referenced schemas to something more appropriate
for the app.

More questions:

1.  Could you please amplify what you mean by "applying derviation by
restriction properly" for this case?  I'm interested because I could
possibly automatically transform the current 'hacky' usage in WSDL files my
code encounters if there were a solid generic solution.

2.  Is what you mean by 'typed wildcards in WXS' something like the general
   <any ... type="anyType"> for the SOAP Array type
and a restriction of this type attribute to this type="tns:ServiceSummary"
in the derived array type of the example below?

Jeff

----- Original Message ----- 
From: "Dare Obasanjo" <dareo@m...>
To: "Jeff Greif" <jgreif@a...>; <xml-dev@l...>
Sent: Monday, July 21, 2003 9:46 AM
Subject: 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>

• References:
  • RE: Must SOAP-based array types be insufficiently validatable?
    • From: "Dare Obasanjo" <dareo@m...>

• Prev by Date: Re: rss regularis(z)ation
• Next by Date: Re: rss regularis(z)ation
• Previous by thread: RE: Must SOAP-based array types be insufficiently validatable?
• Next by thread: rss regularis(z)ation
• Index(es):
  • Date
  • Thread