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 somethin
g that should be discouraged. It would seem to make more sense if "ServiceSummary" was an el
ement 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@[...].edu]
Sent: Mon 7/21/2003 9:09 AM
To: xml-dev@[...].org
Subject: [xml-dev] 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> 




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