counterproposal on issue #144

 Alan,
 (the counterproposal is at the bottom of my text)
 it is true that ordinary native arrays cannot usually hold three
states. On the other hand you don't want to use an ordinary array
for an array of billion nulls and 42 values so you use a
different type anyway.
 In WASP, we deserialize an array (any array) into Java array
(putting nulls in the untransmitted positions) or our custom type
representing a sparse array. Which is used depends on what the
application expects and has in its interface.
 I don't know about VB, though.
 I also understand that sparse arrays can be represented as an
other type, say an associative array (a map), which can be
represented back as a fully transmitted array:
 <sparseArray xsi:type="ns:Map">
    <item><key>42</key><value>blah</value></item>
    <item><key>123456</key><value>foo</value></item>
 </sparseArray>
 This would not be as efficient as native SOAP sparse array, but
it would be a hell of a lot more efficient than a fully
transmitted array. And the point about being (linearly) less
efficient than SOAP sparse arrays is very weak in XML.
 It may be possible to delegate partially transmitted arrays
(ptas) to the XML Type Library and leave it out from SOAP. As
maps, ptas could be even accepted as a de-facto standard risen
from the interop activities.
 So yes, removing ptas from SOAP Encoding is a viable solution,
after all. I think I can propose that as a counterproposal to my
original proposal (ooops, too much proposing here). It means
making array serialization rules about half as complex with no
philosophical issues. It does not affect the resolution of issue
161 and the issue 117 would be automatically closed.
 If this passes, the credit should go to Alan for being stubborn
in the right way. 8-)

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 20 Nov 2001, Alan Kent wrote:

 > 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 06:00:23 UTC