Re: sparse arrays - too complex?

On Thu, Sep 20, 2001 at 09:09:14PM -0400, Rich Salz wrote:
> > say "SOAP interopability is not safe - use another protocol."
> 
> That's ridiculous.  Write real-world code.  If you define services that
> take arrays, nobody sane is going to send you a sparse array that
> happens to have no holes.  If they do, Fault back.

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'.

> Don't cut off the ENTIRE world because SOMEONE might squeeze through a
> loophole.  It's generally not possible to use a human language to write
> a document that has no ambiguity in it.
> 
> Applications that can benefit from spare arrays can benefit big-time;
> it's nice to have a standard way of handling them.  And it's nice to
> have a way to handle legacy RPC systems (DCE and therefore COM/DCOM)
> that provided them, too.

I do not expect sparse arrays to be removed from SOAP (personal
opinions aside). I would however like to see the SOAP spec made
as unambigous as possible (and for it to be possible to write 
SOAP implementations that are as efficient as possible for the most
common cases). Currently:

(1) It is not defined what an omitted entry in an array is. Some people
    say 'it means nil'. Other people say 'it does not mean nil'.

(2) There is currently no standard way to determine if an array can
    be sparse or not, meaning that all arrays could be sparse, so for
    a generic client (1) is a real issue.

My 'analyst' hat analogy is that I think this should be fixed now
before it comes a real issue later. I want SOAP to succeed. To help
that situation, I would like to see the area improved.

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. I can then
write all my applications safely without worrying about sparse arrays.
Its up to SOAP implementors to decide if they support them or not.
I can choose not to support them until the semantics are clearly defined.
At present, my understanding is that I cannot be conformant unless
I support them.

At present, a 'smart' server may decide to encode a returned array
using the sparse encoding rather than send 'nil' value slots in the
array. To some people the sparse encoding is the same as nil, to
others it is not.

Alan

Received on Thursday, 20 September 2001 21:32:07 UTC