Re: Proposal for resolving 144, 161, 117: array serialization

 Noah,
 I intended to indicate exactly that. I'm open to rewordings of
my text because I know very well my English is not nearly good
enough for perfect spec-speak. 8-)

                   Jacek Kopecky

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



On Fri, 21 Dec 2001, Noah Mendelsohn wrote:

 >
 > As I said in my previous note, this looks very good to me overall.  Thanks
 > for pulling it together.  One other comment.   You suggest:
 >
 > >> the member element names needn't even be equal
 >
 > Shouldn't we also indicate that:  "because access to array members is
 > positional, the names of member elements are not significant.  In other
 > words, the array represented by:
 >
 >       <ar xsi:type="enc:Array">
 >             <a>1</a>
 >             <a>2</a>
 >       </ar>
 >
 > is identical to that represented by:
 >
 >       <ar xsi:type="enc:Array">
 >             <a>1</a>
 >             <b>2</b>
 >       </ar>
 >
 > Otherwise, you're back to muti-structs with an array emphasis, I think.  Do
 > you agree?
 >
 > ------------------------------------------------------------------------
 > Noah Mendelsohn                                    Voice: 1-617-693-4036
 > Lotus Development Corp.                            Fax: 1-617-693-8676
 > One Rogers Street
 > Cambridge, MA 02142
 > ------------------------------------------------------------------------
 >
 >
 >
 >
 >
 >
 >                       Jacek Kopecky
 >                       <jacek@systinet.         To:      <xml-dist-app@w3.org>
 >                       com>                     cc:
 >                       Sent by:                 Subject: Proposal for resolving 144, 161, 117: array serialization
 >                       xml-dist-app-req
 >                       uest@w3.org
 >
 >
 >                       12/20/01 09:17
 >                       AM
 >
 >
 >
 >
 >
 >
 >  Hi,
 >  I've been tasked to show in a full form what the proposal on
 > 144, 161 and 117 that removes partially transmitted arrays and
 > sparse arrays from SOAP Encoding looks like. Well, here it is.
 >  The proposal directly addresses 144 and 161, the issue 117 is
 > solved indirectly by removing the attributes that 117 has issue
 > with.
 >
 >
 >  ------------------------------ 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 member element names needn't even be equal (see
 > also section 4.1 rule #2). The members 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 a fixed size.
 >  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. The asterisk, if
 > present, MUST be only on the first position in the list.
 >  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
 > xsd:anyType. Each member's type MUST be a subtype of itemType or
 > it must be the itemType itself.
 >
 >  [stripped examples and schemata updated according to the rules above]
 >
 >  ------------------------------ the proposal end
 >
 > This proposal is the result of amending the original proposal [1]
 > by [2] - stripping partially transmitted arrays and sparse arrays
 > from the text.
 >
 > See [1] for the evolution of this proposal, see [2] for some
 > rationale and for a way of representing sparse arrays if this
 > proposal passes. See also [3], the thread started when the WG
 > solicited feedback from the SOAP builders.
 >
 >
 >                             Jacek Kopecky
 >
 >                             Systinet, Inc.
 >                             http://www.systinet.com/
 >
 > [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Nov/0186.html
 > [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Nov/0192.html
 > [3] http://groups.yahoo.com/group/soapbuilders/message/6468
 >
 >
 >
 >

Received on Friday, 21 December 2001 17:26:40 UTC