ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> wsdl
wsdl
RE: [wsdl] Array definition example in the WSDL spec is invalid
by James Pasley other posts by this author
Dec 14 2001 10:23AM messages near this date
Re: [wsdl] Array definition example in the WSDL spec is invalid | [wsdl] Business Explorer for Web Services
Bob,

sorry to have missed the discussion last month, permit me to reopen it.

Arrays have become quite an issue. However, I think that the WSDL spec is
quite
clear on this issue. Apart from the error in the example, most confusion
comes
from people inventing their own array definitions which are invalid schema.
Ultimately, everyone is free to structure their own array definitions as
they
please. As long as they conform to the rules of XML-Schemas we will have no
difficulty in communicating.

There are many advantages to fixing the array definition as soon as
possible:
as both parsers and application servers mature, it is natural to integrate
validating parsers into the servers - we will make life very difficult for
ourselves if we follow a different set of rules.

It is important to remember that the meaning of the schema is dictated by
the
use attribute in the binding. If it is "literal" then the schema actually
describes the on-the-wire representation of the data type. In this case,
either
client or server may use standard XML-Schema validation mechanisms to
validate
the message. So the example from the spec can never be used with a SOAP
binding
that specifies use="literal".

If we are already committed to using valid (in respect of XML schema) array
definitions for the literal bindings it seems logical to use the same one
for
encoded bindings. Even for bindings that have use="encoded", if a valid
array
definition is used, then any clients apps or tools which understand XML
schemas
will have little difficulty in understanding the message format.

Contrary to what I said in [1], the rules for inheriting attributes are
different
to those for elements. You must repeat all element, but attributes are
inherited
without the need to repeat them. So the references to commonAttributes and
offset
in the proposed interop array definition (shown below) can safely be
omitted.

<complexType name="ArrayOfstring"> 
  <complexContent> 
    <restriction base="SOAP-ENC:Array"> 
      <sequence> 
        <element name="item" type="string" minOccurs="0"
maxOccurs="unbounded" nillable="true"/> 
      </sequence> 
      <attributeGroup ref="SOAP-ENC:commonAttributes"/> 
      <attribute ref="SOAP-ENC:offset"/> 
      <attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="string[]"/> 
    </restriction> 
  </complexContent> 
</complexType> 

This means that the following simpler definition is sufficient:

<complexType name="ArrayOfstring"> 
  <complexContent> 
    <restriction base="SOAP-ENC:Array"> 
      <sequence> 
        <element name="item" type="string" minOccurs="0"
maxOccurs="unbounded" nillable="true"/> 
      </sequence> 
      <attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="string[]"/> 
    </restriction> 
  </complexContent> 
</complexType> 

This should cause no interop problems as it was the extra attributes which
had
the potential to cause problems.

To summarize, the XML-Schema community have done a lot of work in both
defining the standard and developing applications based on it. We should
do everything we can to ensure we can make use of their efforts. We will
be the ones to benefit.

James.


[1]
http://www.capescience.com/library/articles/common-wsdl-errors.html#_Toc5200
9030

-----Original Message-----
From: Bob Cunnings [mailto:cunnings@[...].com]
Sent: Thursday, December 13, 2001 4:44 PM
To: wsdl@[...].com
Subject: Re: [wsdl] Array definition example in the WSDL spec is invalid


Hi James,

Yes. This issue was the subject of some discussion last month.
The Round 2 WSDL had indeed been updated to reflect the new
rules for derivation by restriction. An objection was raised [1],
various futher messages [2][3][4] resulted in a resolution to retain
the form used in the WSDL spec with agreement all around that
the situation is a mess.

Since the focus of the group is SOAP interop first, with WSDL
interop a secondary consideration, I've left the issue on the back
burner, as awkward as it is.

What concerns me is that nothing has been heard for a long time
from the authors of the WSDL spec, on this or any other issue, and
there seems to be no timetable for any revision of the spec.

We've gone around and around on this. Any thoughts?

RC

[1] http://groups.yahoo.com/group/soapbuilders/message/5855
[2] http://groups.yahoo.com/group/soapbuilders/message/5859
[3] http://groups.yahoo.com/group/soapbuilders/message/5855
[4] http://groups.yahoo.com/group/soapbuilders/message/5879

> 
>  The WSDL specification contains the following example of an array of
floats:
> 
>  <complexType name="ArrayOfFloat">
>    <complexContent>
>      <restriction base="soapenc:Array">
>        <attribute ref="soapenc:arrayType" wsdl:arrayType="xsd:float[]"/>
>      </restriction>
>    </complexContent>
>  </complexType>
> 
>  This is invalid as the Schema Primer states that:
> 
>      that types derived by restriction must repeat all
>      the components of the base type definition that are to be
>      included in the derived type
> 
>  The implication of this is that the above definition describes a
>  complexType which can never contain child elements. The use of such
>  definitions causes problems for any software which correctly applies
>  the rules of xml schemas to such definitions.
> 
>  In order for it to contain elements, it must either:
>  	repeat the <xs:any> from the original SOAP array definition
>  or
>  	replace it with a more restrictive definition.
> 
>  There are a number of different ways to define an array. However, the
>  example in the spec should be replaced with the following:
> 
>  <xs:complexType name="ArrayOfFloat">
>    <xs:complexContent>
>      <xs:restriction base="soapenc:Array">
>        <xs:sequence>
>          <xs:element name="item" minOccurs="0" maxOccurs="unbounded"
>  type="xs:float" />
>        </xs:sequence>
>        <attribute ref="soapenc:arrayType" wsdl:arrayType="xs:float[]"/>
>      </xs:restriction>
>    </xs:complexContent>
>  </xs:complexType>
> 
> 
>  To make matters worse, such definitions appear in the interop tests for
>  WSDL.
>  Propagating such invalid definitions even further.
> 
>  We need an errata for the WSDL spec so that the use of this invalid array
>  definition can be prevented.
> 
>  James.
> 
> 
>  Cape Clear Software Limited.
>  61 Fitzwilliam Lane
>  Dublin 2
>  Ireland
> 
>  Email : james.pasley@[...].com
>  Switchboard  : + 353 (1) 2419900
>  Direct line  : + 353 (1) 2419957
>  Fax          : + 353 (1) 2419901
>  www          : www.capeclear.com
> 
>  Visit www.capescience.com
> 
> 
> 
>  To unsubscribe from this group, send an email to:
>  wsdl-unsubscribe@[...].com
> 
> 
> 
>  Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> 




To unsubscribe from this group, send an email to:
wsdl-unsubscribe@[...].com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/


------------------------ Yahoo! Groups Sponsor ---------------------~--> 
Stop Smoking Now
Nicotrol will help
http://us.click.yahoo.com/2vN8tD/_pSDAA/ySSFAA/W6uqlB/TM
---------------------------------------------------------------------~-> 

To unsubscribe from this group, send an email to:
wsdl-unsubscribe@[...].com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
Thread:
James Pasley
Bob Cunnings
James Pasley

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved