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

Hi Jacek,

  My comments are in >>>Murali<<<

>>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

  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

  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. 



-----Original Message-----
From: Jacek Kopecky []
Sent: Monday, November 12, 2001 1:10 AM
To: Murali Janakiraman
Subject: RE: updated proposal on issue #144 - array metadata in SOAP
Encod ing

 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.
 In our framework it's the application that instructs the
serialization layer about how the array is to be serialized and
deserialized - by typing a value as an array or as the class
 I think this is a viable solution without marking the array
(which assumes both sides of the communication want to treat the
array in the same way).
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)

On Thu, 8 Nov 2001, Murali Janakiraman wrote:

 > Hi Jacek,
 >   Allowing position to be optionally specified for some elements of the
 > array could cause problems for those implementations that treat sparse
 > arrays differently.
 >   It is possible to provide a space efficient (and in some real large
 > time efficient as well) implementation for sparse arrays (Imagine some
 > associative structures such as hash-maps that map position to values).
 >   If an implementation treats sparse arrays differently then there needs
 > be a way to unambiguosuly identify such an array. As of now, the only way
 > one can identify an array as a sparse array is by looking at the first
 > element and checking for a position attribute.
 >   Per your proposal, one could get an array with the first element not
 > specifying a position attribute and the later elements specifying
 > This will make it hard or impossible(unless one is willing to look ahead
 > walk through all the elements) to identify an array as a sparse array.
 >   I am not saying every element should have a position attribute if it is
 > sparse array. But there must be some definitive and easy way to
 > an array as a sparse array. This can be achieved in many ways. Add a new
 > attribute isCompact or isSparse or something of that nature. Or insist,
 > array is intended to be trated as sparse then the first element must
 > position attribute.
 > Comments?
 > Murali
 > -----Original Message-----
 > From: Jacek Kopecky []
 > Sent: Tuesday, November 06, 2001 2:17 AM
 > To:
 > Subject: updated proposal on issue #144 - array metadata in SOAP
 > Encoding
 >  Hello all. 8-)
 >  This message is an updated proposal for how we can encode arrays
 > in SOAP Encoding in more XML-like way.
 >  See [1] for background information on this proposal.
 >  Summary of the changes in this update:
 >  1) offset indicates nothing is below it (see [2])
 >  2) elements must appear in order (see [2])
 >  3) Andrew's algorithm (see [3]) added - this removes the
 > constraint that if any member specifies its position, every
 > member in the same array must do so.
 >  4) made rule #8 just point to the subsection on array
 > serialization because otherwise the rule is confusingly long
 > compared with the rest of rules.
 >  ------------------------------ the proposal begin
 >  4.1 rule #8
 >  Arrays are compound values. SOAP Encoding
 > arrays are defined as having a type of "enc:Array" or a type
 > derived there from. See subsection 4.4.2 for specific rules on
 > array serialization.
 >  4.4.2 Arrays
 >  SOAP Encoding arrays have one or more dimensions. An array value
 > is represented as a series of elements reflecting the array. There
 > is no specific constraint on the names of the member elements. The
 > members MUST appear in ascending ordinal sequence; for
 > multi-dimensional arrays the dimension on the right side varies
 > most rapidly.
 >  Array types derived from enc:Array MUST be restrictions of the
 > enc:Array type and can be used to represent, for example, arrays
 > limited to integers or arrays of some user-defined enumeration.
 >  SOAP Encoding arrays can be single-reference or multi-reference
 > values, and consequently may be represented as the content of
 > either an embedded or independent element. The elements which make
 > up the array can themselves can be of any type, including nested
 > arrays.
 >  A SOAP Encoding array MAY contain an enc:arraySize attribute of
 > the type "List of (positiveInteger or '*')" whose items mean the
 > sizes in each of the array's dimensions (unspecified size in case
 > of the asterisk). The number of the sizes representes the number
 > of dimensions of this array. The default value of this attribute
 > is "*". For example, enc:arraySize="3 5" attribute signifies a
 > two-dimensional array with three rows and five columns.
 > enc:arraySize="* 5" signifies a two-dimensional array with an
 > unspecified number of rows and five columns.
 >  In case there is an asterisk on other than the first position,
 > all the members in the array MUST specify their position.
 >  A SOAP Encoding array MAY contain an enc:itemType attribute of
 > the type QName. This type specifies the base type for the type of
 > every member of the array. The default value of this attribute is
 > anyType. Each member's type MUST be a subtype of itemType or it
 > must be the itemType itself.
 >  A SOAP Encoding array MAY contain an enc:offset attribute
 > indicating that there is no member in this array on position below
 > the value of this attribute. This can be used to indicate the
 > offset position of a partially represented array (see
 > Partially Transmitted Arrays).
 >  Likewise, members of an array MAY contain an enc:position
 > attribute indicating the position of that member in the enclosing
 > array. This can be used to describe members of sparse arrays (see
 > Partially Transmitted Arrays). The position attribute MUST
 > NOT indicate a position below the offset (if present) or below the
 > position of the previous member in the array.
 >  The value of the enc:offset and the enc:position attribute is of
 > type "List of nonNegativeInteger" with offsets and positions based
 > at 0.
 >  In the presence of both offset and position the position
 > attribute is absolute, it is not relative to the offset value.
 >  The highest position of a member in an array must not be greater
 > than the size of the array. No two members in an array may specify
 > the same position.
 >  The position of a member is computed assording to the following:
 > If the member has an explicit position attribute,
 >     that position attribute indicates the position exactly
 > Else
 >     If there was a prior element in the encoding,
 >         the member has the position following the prior element's
 >         position in the array,
 >     Else
 >         If there is an offset attribute, position is given by
 >             the value of the offset,
 >         Else position is zero in all dimensions.
 >  [stripped examples and schemata updated according to the rules above]
 > Partially Transmitted Arrays
 >  SOAP Encoding provides support for partially transmitted arrays -
 > arrays in which some members are not transmitted. SOAP Encoding
 > provides two options of skipping some members:
 >  1) skipping the beginning and the ending of an array,
 >  2) specifying the exact positions of members in an array.
 >  The first option uses the attribute enc:offset to specify
 > how much of the beginning of the array is skipped. Skipping the
 > ending of an array is done by simply not transmitting the members
 > at the end. For example:
 > <enc:Array enc:offset="2 2" enc:arraySize="4 3">
 >    <x>3rd row, 3rd col</x>
 >    <x>4th row, 1st col</x>
 >    <x>4th row, 2nd col</x>
 > </enc:Array>
 >  The second option uses the attribute enc:position on the members,
 > following rules set above.
 >  ------------------------------ the proposal end
 >                             Jacek Kopecky
 >                             Systinet, Inc.
 > [1]
 > [2]
 > [3]

Received on Monday, 12 November 2001 16:37:27 UTC