W3C home > Mailing lists > Public > xml-dist-app@w3.org > September 2001

sparse arrays - too complex?

From: Alan Kent <ajk@mds.rmit.edu.au>
Date: Mon, 3 Sep 2001 16:17:02 +1000
To: SOAP <xml-dist-app@w3.org>
Message-ID: <20010903161702.A28121@io.mds.rmit.edu.au>
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.


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:15 UTC