RE: array encoding in SOAP

  I agree with Nova. 

  Also, if SOAP encoding doesn't provide a way to differentiate one compound
type from other (and expects implementations to depend on some other meta
information such as XML Schema), I am not sure of the reasons behind all the
discussions on compound type and array type etc. in Part II Section 3.1.3. I
guess I am not seeing the purpose of these differentiations if the SOAP
encoding doesn't differentiate these types in some way. 

  Also, I am wondering about the reasons behind "itemType" & "arraySize"
attributes. Aren't we kind of saying that it is your (applications) job to
determine something as an array. But, once you have done so, you can use
SOAP specified attributes such as itemType & arraySize for further
processing. I am not sure why we bother with all these if the intention is
to rely upon some other meta information. 

Murali

 
> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: Thursday, May 02, 2002 3:53 PM
> To: Jacek Kopecky
> Cc: Murali Janakiraman; xml-dist-app@w3.org
> Subject: 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:52:58 UTC