- From: Murali Janakiraman <murali@roguewave.com>
- Date: Thu, 8 Nov 2001 16:42:58 -0800
- To: "'Andrew Layman'" <andrewl@microsoft.com>, xml-dist-app@w3.org
Thanks for your comments Andhrew. My replies are inline. >>Andrew Layman >>One of the goals of SOAP, including the encoding, is to avoid >>determining the implementation that must be used. Hence, any >>application is free to store any array in any way the programmer wants. >>There is no necessary rule that sparse arrays must be stored differently >>than full arrays. Agreed. I don't think I meant that sparse array must be stored differently in my previous mail. I only stated that there are some advantages in storing a sparse array as a sparse array in different memory representations. >>Andrew Layman >>See also the discussion on the SOAP Builders list pointing out that >>sparse arrays as a transmission concept do not imply that the actual >>array held by the sender or receiver is sparse. See the thread >>containing http://groups.yahoo.com/group/soapbuilders/message/5145 . No problems with this as well. >>Andrew Layman >>I believe that what you are asking for amounts to wanting a clue at the >>start of an array advising you that the array is sparse. (How sparse?) Yes, that is what I am asking for so that the receiving app can map it into its data model appropriately. >>Andrew Layman >>I suggest thinking of the utility of the clue, not for how the present >>versus absent elements should be encoded. I don't seem to understand what you mean here. In any case, I think sparse array is an important concept. Though the wire format of SOAP doesn't necessitate a specific implementation, I don't see a reason why we should necessarily make it hard for those who may want to treat sparse arrays differently than a compact/regular array. I don't think providing a clue for sparse array insists on a specific implementation. Murali -----Original Message----- From: Murali Janakiraman [mailto:murali@roguewave.com] Sent: Thursday, November 08, 2001 10:31 AM To: 'Jacek Kopecky'; xml-dist-app@w3.org Subject: RE: updated proposal on issue #144 - array metadata in SOAP Encod ing 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 arrays 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 to 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 positions. This will make it hard or impossible(unless one is willing to look ahead and 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 a sparse array. But there must be some definitive and easy way to understand 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, if array is intended to be trated as sparse then the first element must specify position attribute. Comments? Murali -----Original Message----- From: Jacek Kopecky [mailto:jacek@systinet.com] Sent: Tuesday, November 06, 2001 2:17 AM To: xml-dist-app@w3.org 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 4.4.2.1 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 4.4.2.1 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] 4.4.2.1 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. http://www.systinet.com/ [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0295.html [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0362.html [3] http://groups.yahoo.com/group/soapbuilders/message/5126
Received on Thursday, 8 November 2001 19:43:32 UTC