Re: sparse arrays - too complex?

 Alan,
 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
nil.
 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

                            Idoox
                            http://www.idoox.com/



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