W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2002

Re: array encoding in SOAP

From: Robert van Engelen <engelen@cs.fsu.edu>
Date: Thu, 2 May 2002 21:20:27 -0400 (EDT)
Message-Id: <200205030120.g431KRj13265@diablo.cs.fsu.edu>
To: noah_mendelsohn@us.ibm.com
Cc: jacek@systinet.com (Jacek Kopecky), murali@roguewave.com (Murali Janakiraman), xml-dist-app@w3.org

I agree with Noah.

Meta-information can go a long way to deterministically and unambiguously
determine data content. However, WSDL does not reveal information that
often is an essential part in the demarshalling process for arrays.
Certain SOAP implementations use the arraySize attribute value to pre-allocate
space for the elements. Without this information, a vector or linked-list
representation is the only viable alternative to hold an array. Since arrays
are usually native data types in program languages, removing the arraySize
attribute will provide essential information for many SOAP-to-language-X
bindings. I believe that the removal of the arraySize attribute from
enc:array types is a mistake. The presence of the itemType attribute on
the other hand is not essential. If the array contains elements of the same
type then this information is available in the WSDL. The type of elements of
polymorphic arrays are identifyable by their xsi:type attribute values.
Another issue that will be hampered by the removal of arraySize attribute is
the demarshalling of multi-dimensional arrays with varying row/column sizes.

IMHO:

1. The arraySize attribute should be mandatory for schema types based on
   enc:array. One can always define a new array-like schema type that
   does not require this attribute (!).
2. The itemType attribute is optional and should reflect the type provided
   in the definition of the array in the WSDL schema.
3. I regret the removal of the offset attribute and the general removal
   of sparse arrays. It violates orthogonality of the SOAP data model.

The reason why I believe that orthogonality is violated by the removal of
sparse arrays is simple:

Structs and generics are complexTypes with elements that can be nil or
absent ("empty").

Arrays are complexTypes with elements that can be nil BUT NOT ABSENT
("empty") because array elements are identified by position.

The SOAP 1.1 data model elegantly used position attributes as a means
to encode arrays with absent elements. IMO the removal of the position
attribute from SOAP 1.2 should be very carefully considered. I think
that Don Box was right in his view for the need of sparse and partial
arrays to make the data model sound and complete.

- Robert

> Jacek Kopecky writes:
> 
> >> I believe this is not a problem because the 
> >> (de)serialization code usually follows some 
> >> kind of a schema telling it which nodes 
> >> are of what type as listed above - for example 
> >> an XML Schema  schema in a WSDL file, or the 
> >> structure of the actual data types in the 
> >> implementation.
> 
> Whatever the merits of our current array/struct design,  I think it is a 
> mistake to assume that all interesting SOAP implementations will always 
> use a schema description such as WSDL to decode messages.  The ability to 
> map individual self-describing messages into dynamically typed languages, 
> such as scripting languages, seems to be very useful.   It is a capability 
> that SOAP has had to a significant degree since day one, or at least since 
> xsi:type has been supported.  It certainly was a capability that we 
> discussed explicitly when writing the specification for SOAP version 1.1.  
> I think we should accept a principal that enabling (but not requiring) a 
> reasonable ability to send self describing messages is a good goal.  To 
> not do so would be a step backward from earlier versions of SOAP.  That 
> said, I am not arguing for a change to wear existing facilities for arrays 
> or other structured types. 
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 
> Jacek Kopecky <jacek@systinet.com>
> Sent by: xml-dist-app-request@w3.org
> 05/02/2002 06:19 PM
> 
>  
>         To:     Murali Janakiraman <murali@roguewave.com>
>         cc:     xml-dist-app@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        Re: array encoding in SOAP
> 
> 
>  Murali,
>  I've CCed the dist-app list for I think many can be interested 
> in this.
>  In SOAP Encoding on-the-wire format, we don't identify the type
> of a node - whether it is a compound or a terminal, and whether a 
> compound is a struct, array or generic. 
>  It is true that a terminal with an empty content is 
> indistinguishable from an empty struct or array. It is also true 
> that a struct can be viewed as an array anytime.
>  I believe this is not a problem because the (de)serialization 
> code usually follows some kind of a schema telling it which nodes 
> are of what type as listed above - for example an XML Schema 
> schema in a WSDL file, or the structure of the actual data types 
> in the implementation.
>  I don't have a sound technical reason for my belief, it's just
> that this never seemed a problem before. On the other hand, had 
> we designed SOAP Encoding from the scratch, we might have decided 
> to make the XML instances fully self-describing.
>  Best regards,
> 
>                    Jacek Kopecky
> 
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
> 
> 
> 
> On Thu, 2 May 2002, Murali Janakiraman wrote:
> 
>  > Hi Jacek,
>  > 
>  >   Thought you will know the answer to my doubt as you have been closely
>  > associated with encodings and arrays.
>  > 
>  >   I think I haven't looked at SOAP encoding WRT arrays for a long time 
> and
>  > looked it recently.
>  > 
>  >   Now that "arrayType" attribute is gone and "itemType" and "arraySize"
>  > attributes are optional I was wondering how would one identify a given 
> wire
>  > format of a compound type as a struct or as an array? At least I am not
>  > finding (within the SOAP provided means) to deterministically identify 
> a
>  > given format as an array. For example,
>  > 
>  >   <canThisBeAnArray>
>  >      <item xsi:type=xsd:int>10</item>
>  >      <item xsi:type=xsd:int>20</item>
>  >   </canThisBeAnArray>
>  > 
>  >   Can this be considered an encoding of an array? If so, why? 
>  >   (I am assuming encodingStyle is set to soap encoding somewhere at a 
> higher
>  > level)
>  > 
>  >   Would appreciate your reply.
>  > 
>  > Thanks,
>  > 
>  > Murali
>  > 
>  > Rogue Wave User Conference in Vail, Colorado, July 2002! :
>  > http://www.roguewave.com/corp/events/usersgroup/
>  > 
> 
> 
> 
> 


-- 
    Robert van Engelen: Assistant Professor, Computer Science Department
   Florida State University, 253 J. Love Bldg., Tallahassee, FL32306-4530
     Offices: 162LOV/471DSL, (850)644-9661/645-0309, Fax: (850)644-0058
       Email: engelen@cs.fsu.edu, URL: http://www.cs.fsu.edu/~engelen
Received on Thursday, 2 May 2002 21:20:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:10 GMT