W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2001

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

From: Alan Kent <ajk@mds.rmit.edu.au>
Date: Tue, 20 Nov 2001 19:51:16 +1100
To: xml-dist-app@w3.org
Message-ID: <20011120195115.T10991@io.mds.rmit.edu.au>
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 03:51:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:05 GMT