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

While the element names are not significant qua array element, they may
be significant in other ways, such as affecting the post schema
validation infoset, I would think.

-----Original Message-----
From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com] 
Sent: Friday, December 21, 2001 12:16 PM
To: Jacek Kopecky <jacek
Cc: xml-dist-app
Subject: Re: Proposal for resolving 144, 161, 117: array serialization


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 Wednesday, 26 December 2001 16:49:04 UTC