RE: latest proposal on issues #144 and #161 - array encoding

Maybe I am missing something, in which case I beg forgiveness, but I am
puzzled.  I thought that a Java array declared as Integer[] could easily
allow null elements.

Whether the receipt of a sparse array sets the omitted elements to null
or leaves them untouched is not a matter of the array encoding itself,
but of the semantics of the message in which the array appears.  That
is, some messages may have CREATE semantics and others UPDATE semantics.
This is not surprising, any more than that a number such as "100" has
context-dependent meaning.  In some messages it might mean "set my bank
balance to 100" and in others it could mean "add 100 to my bank
balance".

   

-----Original Message-----
From: Alan Kent [mailto:ajk@mds.rmit.edu.au] 
Sent: Tuesday, November 20, 2001 12:51 AM
To: xml-dist-app@w3.org
Subject: Re: latest proposal on issues #144 and #161 - array encoding

On Tue, Nov 20, 2001 at 09:41:08AM +0100, Jacek Kopecky wrote:
>  Alan,
>  personally I agree with you that in-spec two-state arrays might
> be the right way to proceed.
>  On the other hand, when we discussed the issue in the ETF, there
> was an equally strong push in the direction of "omitted may mean
> leave the current value in there, nil is a nil".

I can understand this, I just think that forcing *all* arrays
to support 3 states per slot is an unnecessary burden.
I have to go right now, but think of languages like VBScript.
(I am NOT a VBScript expert by the way.) VBScript uses
Variants to hold values. It also supports null. If you want
to use a 3-state SOAP array, exposing this to VBScript becomes
non trival. You cannot just use an array.

Java is the same story. With 2-state you can define Integer[]
(I am not a Java programmer either! :-) to be an array of
integer objects (I think!) where null can be stored in the array.
3-state logic cannot be represented using native Java arrays.
Instead you must define a new class. Oh, but if you define a new
class, you must define a new class per array type (array of string,
array of boolean, array of struct X etc). Yes it can be done,
but boy is it messy. Its much nicer using the language's native
arrays.

It just seems a real pitty that because of some small percentage
of usage (lets face it, parital arrays are not going to be common)
is going to have a big impact on the implementation of *all* array
types.

So I strongly favor, for purely practical reasons, either making
them a separate type, or simplifying them so omitted is the same
is NIL (or remove them altogether and push them into application
semantics instead of putting them into the lowest level of SOAP).
I do not see why everyone's possible use for arrays needs to
be supported. If people want more complex types (such as partial
arrays), let them use an XML schema to encode the information.
The offsets/positions attribute approach is not the only way to
allow p-t-a arrays to be supported by soap.

Got to go
Alan

Received on Tuesday, 20 November 2001 17:01:10 UTC