Feedback

Dear Glen,

My research group developed the gSOAP toolkit. The toolkit fully supports
sparse and p.t. arrays [1]. Removal of sparse and/or p.t. arrays would bother
me, my group, and all the users of gSOAP.

> 1) Do you use P.T./sparse arrays currently?  If so, what are the scenarios
> (array updates, avoiding sending lots of nulls, etc...)?

Users of the gSOAP toolkit use sparse and p.t. arrays. For example, we have a
linear solver service that accepts sparse and p.t. arrays [2].

Our SOAP toolkit has matured significantly over the last two (!) years.
We started two years ago implementing XML-RPC and quickly moved on to SOAP.
The SOAP 1.1 spec. was very clear on the sparse and p.t. arrays in my opion
and we did not find any problems in our interop tests that we conduct with
many other SOAP implementations [3] [4].

> 2) Would it bother you to see them go away in SOAP 1.2?

Sparse and p.t. arrays are convenient to use for all kinds of applications.
IMHO, a SOAP standard should not be changed if the use is "difficult" or
"redundant". IMO sparse/p.t. arrays are certainly not redundant.  From
a theoretical point of view, they form a subtype hierarchy:

array < partially transmitted array < sparse array

This subtype hierarchy distinguishes the types bases on the observation that
omission != null (see discussions on omission==null in
soapbuilders@yahoogroups.com). IMO, omission == null is a dangerous
assumption. At least it is SAFE to assume that omission!=null. For example,
one can argue that the presence of xsi:nil is actually a value (be it a nil
value) for an element which has to be distinguished from the omission of an
element. With this SAFE assumption, a sparse array is semantically different
compared to a "regular" array with lots of xsi:nil elements to obtain the same
effect. Therefore, the existence of sparse arrays can be perfectly motivated.

Another reason for not removing sparse arrays from the spec is that the
decision to use sparse vs. regular arrays can be taken at the application layer.
This is currently hampered by the expresiviness of arrays in WSDL.
IMO the sparse array problem can be solved by including appropriate
annotations for arrays in WSDL to indicate the use of sparse/p.t./regular 
arrays. So a client of a service that does not support sparse arrays is
informed about this in the WSDL. For example:

  <complexType name="ArrayOfint" base="SOAP:Array">
     <complexContent>
         <restriction base="SOAP-ENC:Array">
	      <attribute ref="SOAP-ENC:arrayType" WSDL:arrayType="int[]"
	        WSDL:arraySparse="false" WSDL:arrayPartial="false"/>
	 </restriction>
     </complexContent>
 </complexType>

This WSDL spec indicates that sparse and p.t. arrays are not supported.

To conclude, it would bother me and many gSOAP if sparse arrays are removed
from the specification and I believe there are other solutions such as the
incorporation of annotation in the WSDL type part to restrict the use of
sparse and p.t. arrays for applications that don't support these forms.

- Best regards, Robert van Engelen, Professor in Computer Science

[1] http://www.cs.fsu.edu/~engelen/soap.html
[2] http://www.cs.fsu.edu/~engelen/lu.wsdl
[3] http://www.cs.fsu.edu/~engelen/interop2results.html
[4] http://www.cs.fsu.edu/~engelen/interop2Bresults.html

Received on Thursday, 13 December 2001 15:09:45 UTC