Re: array encoding in SOAP

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/
 >

Received on Thursday, 2 May 2002 19:10:36 UTC