- From: Alan Kent <ajk@mds.rmit.edu.au>
- Date: Mon, 3 Sep 2001 16:17:02 +1000
- To: SOAP <xml-dist-app@w3.org>
I just finished typing up a carefully crafted question on soap arrays that took an hour to compose. Then lost it. <:-( Here is a cut down version the second time around. After finishing an implementation of SOAP, I have come to the *personal* opinion that sparse arrays add a lot of complexity, slow down implementations for no benefit to the majority of applications. There is also a discussion on the interoperability list now going on to which the response seems to be that every slot in an array can be one of three states: hold a value, be nil, or not be present (which is different to nil). This three state logic makes implementation of library code painful. To me sparse arrays are useful only a small percentage of the time and so should be removed from the low level SOAP protocol and moved to the layer built on top. For example, use an array of complexType with two elements - one for the key, and one for the value. An alternative is to allow a WSDL file somehow say that this array is sparse (with the default being the array must not be encoded using the sparse representation). At present *all* arrays could be encoded using the different sparse representation with positions and offsets. This means that all libraries have to worry about this complexity. Alan ps: I have similar concerns about nil values (for example, you cannot decode a C++ array of int's as the array may have a nil in it) and href=. In both cases every element being decoded has to perform additional checks, which adds up if performance is a concern.
Received on Monday, 3 September 2001 02:17:35 UTC