RE: Subject: RE: wsdl:types and arrays

The book is wrong. The spec does not say MUST. The discussion regarding
array types follows this preamble (note particularly "in these cases"):

"The XSD type system can be used to define the types in a message regardless
of whether or not the resulting wire format is actually XML, or whether the
resulting XSD schema validates the particular wire format. This is
especially interesting if there will be multiple bindings for the same
message, or if there is only one binding but that binding type does not
already have a type system in widespread use. In these cases, the
recommended approach for encoding abstract types using XSD is as follows:"

First of all, you are using XML on the wire. Second, the XSD type system is
in widespread use. You can use any valid XML Schema type definition.

Anne

> -----Original Message-----
> From: Mats Henricson [mailto:mats_henricson@yahoo.com]
> Sent: Thursday, December 12, 2002 1:12 AM
> To: www-ws-desc@w3.org; donmullen@tibco.com; ryman@ca.ibm.com;
> mgudgin@microsoft.com; anne@manes.net; jacek@systinet.com;
> sanjiva@watson.ibm.com
> Subject: Subject: RE: wsdl:types and arrays
>
>
> Hi!
>
> My concern about wsdl:types being incompatible with XSD
> maxOccurs='unbounded' comes from the book "Building Web
> Services with Java", published in December 2001 by SAMS,
> ISBN 0-672-32181-5.
>
> On page 341 it says:
>
>    Normally, to define a type that contains a repeating
>    group of elements, you would use the following style
>    of XML schema:
>
>      <xsd:complexType name="registrationRequest">
>        <xsd:sequence>
>          <xsd:element name="items"
>             type="xsd:string" maxOccurrs="unbounded" />
>
>    However, in WSDL, repeating groups such as this must
>    be modeled using the array data type from the SOAP
>    encoding namespace
>    (xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/").
>    This is another jarring example where an aspect of
>    the message encoding (really the domain of the binding
>    element, as we will see in the next section) imposes
>    itself on the base datatyping mechanism in WSDL. This
>    is an artifact of the common use of WSDL to model SOAP
>    messages. So, regardless of weather your Web service
>    uses SOAP, you need to use the array datatype from the
>    SOAP encoding namespace to model repeating groups. The
>    following snippet shows the registrationRequest type:
>
>      <xsd:complexType name="registrationRequest">
>        <xsd:sequence>
>          <xsd:element name="items">
>            <xsd:complexType name="ArrayOfItem">
>              <complexContent>
>                <restriction base="soapenc:Array">
>                  <attribute ref="soapenc:arrayType"
>                    wsdl:arrayType="xsd:string[]"/>
>                </restriction>
>              </complexContent>
>            </complexType>
>          </xsd:element>
>
> OK, the book is old (one year), and it may be flat out
> wrong, but the text that assumedly describes this
> restriction, section 2.2 in the old version of WSDL, has
> not been changed.
>
> So, this leaves us with two possibilities:
>
> 1. The book is wrong
> 2. The book is right
>
> I assumed the book was right, which made me send you the
> original message.
>
> If the book is wrong, then why do we have a section in
> the standard that talks about this? Why can't we just
> totally throw away that text and replace it with a blank
> statement that any valid XSD can be in the wsdl:types
> section in a WSDL file? The troubling text is:
>
>    Array types should extend the Array type defined in
>    the SOAP v1.1 encoding schema...
>
> I'm not sure if "should" means what it does, according to
> IETF RFC 2119. Can I use my maxOccurrs="unbounded" any
> way I want?
>
> Mats
>
> PS. Sorry for late reply. I just got myself a new job,
>     plus a dead computer at home.
>
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
>

Received on Thursday, 12 December 2002 10:40:38 UTC