RE: counterproposal on issue #144

 Andrew,
 if we resolve your first issue by means of type out of SOAP
Encoding, it automatically resolves your second issue because
that type is different from SOAP:Array (probably an application -
restriction thereof).
 Even if we decide to keep partially transmitted arrays (the
original proposal), there has been some discussion that it's the
application that can provide the up-front clue to itself anyway
(because the application knows it's dealing with ptas or just
with arrays).
 So to summarize:
 My original proposal resolves 1 directly, and resolves 2 by
saying that applications know.
 My counterproposal resolves both directly.
 Yes there might be a different proposal with different handling
of your second issue while keeping ptas in SOAP Encoding. I just
feel it's adding unnecessary complexity.
 Best regards,

                   Jacek Kopecky

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



On Tue, 20 Nov 2001, Andrew Layman wrote:

 > There seem to be two issues here:
 >
 > 1.	If only some elements from an array are to be encoded, how that
 > should appear lexically.
 >
 > 2.	Applications may benefit, perhaps substantially, if they have an
 > up-front clue regarding whether a conventional array or an associative
 > array is the more efficient storage.
 >
 > The first is addressed by the current SOAP section 5 rules; the second
 > is addressed by various suggestions to make sparse arrays a distinct
 > datatype or otherwise mark the containing element.  I recommend that we
 > not conflate the two issues.
 >
 >
 >
 > -----Original Message-----
 > From: Jacek Kopecky [mailto:jacek@systinet.com]
 > Sent: Tuesday, November 20, 2001 3:00 AM
 > To: Alan Kent
 > Cc: xml-dist-app@w3.org
 > Subject: 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 Wednesday, 21 November 2001 05:16:36 UTC