Re: sparse arrays - too complex?

On Thu, Sep 20, 2001 at 09:37:57PM -0400, 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.

A part of my point is that servers are currently allowed to return a
sparse array encoding at any time (and one of the SOAP servers I tried
did from memory) even when the array was fully populated. Also, if
you say 'omitted sparse element = nil', then a server is allowed
to use a sparse array instead of sending nil elements in an array.

The semantics are therefore for *any* array of any method.
This is a problem for the encode/decode SOAP libraries. These
libraries do not need to understand the semantics of method "Foo".
They do however need to know how to encode/decode legal SOAP
packets into programming language data structures.

Does this mean for my toolkit I should say 'for every array you have
to define whether an omitted element means null or not'. This would
lead to 3 values in the WSDL file (for example):
- array is never sparse
- array is sparse where omitted means value is nil
- array is sparse where omitted means value is omitted

The above would satisfy mean without any change to the SOAP spec,
so I might put it into my own tool kit. To use my toolkit against
another server you *may* need to tweak the WSDL file used to
generate the correct source code I automatically generate from
the WSDL file.

OK - I am sated. I have a way forward.

Alan

Received on Thursday, 20 September 2001 23:04:11 UTC