Re: sparse arrays - too complex?

 Hello all. 8-)
 Let's assume for a while that an omitted accessor in a sparse
array means nil (I'll call this a two-state sparse array). The
implementors' situation is simple with such an assumption.
However, this disallows sending of "diff" arrays where nils can
also be transmitted.

 Well then, let's assume for a while that an omitted accessor is
not a nil (three-state sparse array). For example (in pseudo
code):

a[2] = 1; a[4] = nil; transmit(a);

 and the resulting sparse array with two items could mean
"receiver of this array will update its own version of the array
by putting 1 in the third position (counting from zero) and a
nil into the fifth position, the rest will stay the same."
 This sounds a lot like application logic but it does require the
ability to transmit three states. This can be worked around if we
don't have three-state sparse arrays.
 As an implementor, I agree that three-state sparse arrays are a
big complication that can be worked around quite simply by using
different means of serializing the "diff".
 Two-state sparse arrays are just a means of transmitting an
array with nils more efficiently. As such, they could be omitted
from the spec with no real loss of functionality.
 I support two-state sparse arrays or omission of sparse arrays
in this order of preference. 8-)
 Anyway, this needs to be cleared up in the spec, but that's a
task for the encoding task force (that had been planned for this
fall).

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/



On Thu, 20 Sep 2001, Rich Salz wrote:

 > > My point is that if I write a client, a server may at any time return
 > > an array with holes which may have a meaning that is important from
 > > the server perspective, but the protocol does not tell me what it means.
 > > It could be nil, it could be 'not present'.
 >
 > The point others are making is that this is part of the server semantic,
 > so just as you know what the "Foo" operation does -- even though only
 > its calling sequence is expressed in XML -- you need to know what a
 > returned sparse array means.
 >
 > > Personally, I think the solution most likely to succeed in the real
 > > world is to add something to a WSDL file saying 'this array can be
 > > sparse' where the default is that arrays cannot be sparse.
 >
 > Sure, WSDL already has enough crocks, er extension elements, that this
 > seems like the place to put it.
 >
 > > To some people the sparse encoding is the same as nil, to
 > > others it is not.
 >
 > Yup, and it depends on the application.  This makes the situation
 > difficult for generic clients.  I feel your pain.
 > 	/r$
 >

Received on Friday, 21 September 2001 04:21:39 UTC