RE: sparse arrays - too complex?

Per the spec, omitting an accessor and having it with xsi:nil="true" MAY
or MAY NOT be equivalent.  The spec leave open all possibilities.  Some
implementations of structure serialization evidently choose to treat
them as equivalent representations, but neither the SOAP nor the XML
Schemas specification requires this. 

-----Original Message-----
From: Jacek Kopecky [mailto:jacek@idoox.com] 
Sent: Thursday, September 20, 2001 5:52 AM
To: Alan Kent
Cc: SOAP
Subject: 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 14:36:11 UTC