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

Re: sparse arrays - too complex?

From: Jacek Kopecky <jacek@idoox.com>
Date: Thu, 20 Sep 2001 14:51:44 +0200 (CEST)
To: Alan Kent <ajk@mds.rmit.edu.au>
cc: SOAP <xml-dist-app@w3.org>
Message-ID: <Pine.LNX.4.33.0109201443210.29512-100000@mail.idoox.com>
 I disagree that there are three states for array values.
 In structures, omitting an accessor and having it with
xsi:nil="true" is equivalent. I see sparse arrays as exactly the
same for arrays where you cannot just omit an item to make it
 This is also how we implement sparse arrays - putting NULLs
where the item is not present. We optionally generate sparse
arrays when the array that is being serialized contains NULLs.
 You can easily represent a SOAP array of ints as C++ array of
pointers to ints so I don't see why nillable content adds
trouble. We have implemented it with no problems coming from
sparse array support.
 Every discussion about nils and nothings seems to be endless,
though. 8-)

                            Jacek Kopecky


On Mon, 3 Sep 2001, Alan Kent wrote:

 > 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 Thursday, 20 September 2001 08:51:45 UTC

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