RE: wsdl:types and arrays

OK, case closed from my perspective.
Much thanks for your patience!

Mats

> The book is wrong, although somewhat understandably given the WSDL 1.1 text.
> 
> FYI: Current status quo of WSDL 1.2 is that it won't directly support SOAP
> encoding.
> 
> That said, we do have a problem with current WSDL 1.2 public and editor's
> copy specification:
> 
> 3.4.1 Guidelines for Using XML Schema
> "Array types should extend the Array type defined in the SOAP v1.1 encoding
> schema "http://schemas.xmlsoap.org/soap/encoding/" (regardless of whether
> the resulting form actually uses the encoding specified in Section 5 of
> [SOAP 1.1])."
> 
> This should be cleaned up.
> 
> Don
> 
> -----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


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Received on Friday, 13 December 2002 18:15:48 UTC