Re: sparse arrays - too complex?

Wouldn't a sparse array be better treated as a hash, anyway? I agree with
Alan on this - I found the sparse arrays to be really problematic for very
little return, and eventually resorted to a hash scheme instead.

-- Kurt Cagle

----- Original Message -----
From: "Alan Kent" <ajk@mds.rmit.edu.au>
To: "SOAP" <xml-dist-app@w3.org>
Sent: Sunday, September 02, 2001 11:17 PM
Subject: sparse arrays - too complex?


> 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 11:50:00 UTC