OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Famous web services with apparent serious XML schema errors

[ Lists Home | Date Index | Thread Index ]

I'm working on an application that needs to be able to read and rely on the
XML Schema information contained in or referenced from web service
descriptions (WSDL), since it is supposed to be able to dynamically interact
with any web service so specified.  While this is possible with many web
services, it seems that developers of these descriptions sometimes propagate
a common set of what I believe to be erroneous schema constructs and usages.
The the schemas are
a.  invalid
b.  fail to define the types that were intended
and the instances returned from the web services are invalid with respect to
the schemas.

The common errors (if I am not confused!) are:

1.  Using the http://schemas.xmlsoap.org/soap/encoding/ namespace (the URL
can be dereferenced to get the schema) and referring to its types without an
<import> in the schema.  The schema thus will not be accepted by a schema
validator.

2.  Definition of array types based on the soap encoding, like this:
<xsd:complexType name="AuthorArray">
    <xsd:complexContent>
     <xsd:restriction base="soapenc:Array">
      <xsd:attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:string[]"/>
     </xsd:restriction>
    </xsd:complexContent>
This derivation fails to copy the unchanged content from soapenc:Array
(basically a repeating <any>), so instead of defining a homogeous array, it
specifies empty content..[1]  Xerces tells me so when I hand it an instance:

2:1204 - cvc-complex-type.2.1: Element 'Authors' must have no character or
element information item [children], because the types content type is empty

but apparently I'm the only one who ever validates data returned from web
services.  What was intended was something functionally equivalent to this
<xsd:complexType name="AuthorArray">
  <xsd:sequence>
     <xsd:element name="Author" type="xsd:string"  minOccurs="0"
maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexContent>
apparently using the soap encodings to get higher efficiency by having
attributes that can be parsed to determined the number of items in the array
and their type.

3.  For some reason, possibly to satisfy the caprices of some early soap
tools, the services return results that look like this:
<Authors SOAP-ENC:arrayType="xsd:string[2]"
xsi:type="SOAP-ENC:Array">
  <Author xsi:type="xsd:string">Reiner Westermeier</Author>
  <Author xsi:type="xsd:string">Tom Naven</Author>
</Authors>
Xerces correctly rejects these also, since the declared type of Authors is
derived from the xsi:type, which is backwards and illegal.  (Notice that the
soap-enc:arrayType is a typo -- should be "tns:Author[2]").

What are the services I've sampled?  Google and Amazon are the two offenders
I've been working with as tests of my application .  One wonders how many
others are copying what they've done, or what book they've consulted to
learn these 'tricks'.  I found several others on xmethods.net.  Presumably
Web Services, if they have a real future in significant business processes,
will have to conform to standards well enough that programs can validate
their specifications and validate their results against those
specifications.

Jeff

[1] The relevant discussion in the schema spec is just below
http://www.w3.org/TR/xmlschema-1/#Complex_Type_Definition_details
in the description of the [content type] infoset item, #1.1





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS