RE: updated proposal on issue #144 - array metadata in SOAP Encoding

 Murali, but also Alan,
 I think the issue here is the true meaning of the term "sparse
array".
 In math we have the term "sparse matrix" meaning "a matrix
containing mostly zeros". Mostly is a very vague word, I am not
aware of any stricter quantification of how many zeros must a
matrix contain to be considered sparse.
 The same with SOAP arrays - how many members can be present for
the array to be still considered a sparse array?
 In my proposal the term "sparse array" is only used once and it
points to the section about "partially transmitted arrays".
 The problem is that one application can consider an array and an
other application can treat the same array as just an array. If
we add the attribute isSparse (or any other suitable name), what
do we communicate on the wire? It is a hint to some
implementations. It's like if we wanted to add an attribute on
transmitted integers that thay are in fact in the range -128 to
127 and therefore fit into a common byte:
 <a xsi:type="xsd:integer" enc:isByte="true">42</a>
 This comparison leads me to thinking that we might add a new
type, SparseArray, being a restriction of the type Array with
just the annotation "these arrays are sparse", just like we have
xsd:byte type.
 But how do we define a sparse array? If anybody comes with a
definition suitable for the spec, I think we could add the type.
 What d'ya think? 8-)

                   Jacek Kopecky

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



On Mon, 12 Nov 2001, Murali Janakiraman wrote:

 > Hi Jacek,
 >
 >   My comments are in >>>Murali<<<
 >
 > >>Jacek
 > >>in my opinion the entity that knows best the array are or are
 > >>not sparse is the application. The serializer cannot reliably
 > >>guess an array it's serializing is sparse unless it scans through
 > >>a significant portion of the array which may be very inefficient.
 >
 > >>> Murali
 >
 >   I am sorry, I disagree. I don't see any reason why any guessing (as to
 > what is being sent on the wire) has to be done on the sender side unless the
 > sender side consists of improperly designed dis-joint pieces.
 >
 >   First, let me state here that, IMO, your distinction of serializer and
 > application is very implementation centric. From the point of view of SOAP
 > there is no notion of serializer, there is just the SOAP defined wire format
 > for SOAP defined data model and there is a sender who is sending an array
 > (or whatever) under SOAP defined encoding rules.
 >
 >   The sender (irrespective of the number of layers it is built up of -
 > serializer, application or whatever) knows what it is sending and that is
 > true for sparse arrays as well (in your layered approach if an application
 > cann't communicate this to its serializer it indicates an issue with the
 > design of the serializer and it has got nothing to do with SOAP and its
 > encoding).
 >
 >   On the other hand, if the wire format of sparse arrays does not
 > unambiguously identify it as a sparse array, then the receiver has to do the
 > guess work (ofcourse, only if the receiver wants to treat the sparse array
 > differently)
 >
 >   So, the question seems to me, why don't SOAP that seems to be supporting
 > sparse array as a first class citizen doesn't allow the sender to say it so
 > in a SOAP defined way, so that the receiver can appropriately deal with it.
 >
 > <<<Murali

Received on Tuesday, 13 November 2001 06:44:32 UTC