RE: [soapbuilders] FEEDBACK REQUESTED - Issues regarding Array encoding for SOAP 1.2

 Matt, Andrew, others,
 we support partially transmitted arrays 100% as well. However,
we support removing that part of the spec because partially
transmitted arrays can be modeled using normal arrays and
structures just like maps and sets are.
 Let's try to understand what we want from arrays. Well, at the
very basic, we want to transport a bunch of values whose names
are, actually, just numbers, because the roles of the various
values are not different.
 Additionally, we might want to conserve bandwidth by optimizing
NULLs away - let me mark this as the goal A. (A suspicious goal
in XML, I think, but that doesn't matter in this discussion.)
 For more, we may want to be able to transmit a subset of the
bunch of values, with their respective names - the goal B. The
natural way is to transmit a bunch of tuples <index, value>. That
would be an array of structs with the members 'index' and
'value', right?
 In SOAP, partially transmitted arrays try to achieve one of the
goals. SOAP does not say which, and that's the problem. If we
settle on A, I'll be OK with it. If we settle on B, my problem
would be that we don't provide such native support for maps, for
example, as maps are on the same level as partially transmitted
arrays. Why should we favor p-t-as over maps? My experience tells
me maps are much more common than p-t-as anyway. Oh, BTW, maps
and sets and all that are already being used, too, without direct
support of SOAP Encoding - they are built on top of it quite
nicely.
 There is also the seeming inconsistence in structs where omitted
members are allowed and arrays, where we might disallow them. The
inconsistence is really not there because the ability to omit
members of structs has a different rationale behind it than in
arrays.
 For structs, if an omitted member means the default (may be a
NULL, actually), an evolution of applications is enabled - a
slightly more advanced version of a server accepts some members
in the structure that the older version does not accept, why
should it fail if it can handle the 'simpler' structures by
adding defaults on the new members?
 In arrays, no such evolution of the structure can occur, though.
The reason for omitting members of arrays is one of the goals
stated above and either is very different from the reason of
allowing omitting members of structures.
 So basically, I say if we remove p-t-as from SOAP Encoding, we
lose a hacky optimization of a rare usecase and we gain general
simplicity.
 Let's remember that SOAP Encoding is a _wire_format_ and
higher-level semantics can be given to structs and arrays that
come on the wire.
 Best regards, and apologies for writing such a long email again,

                   Jacek Kopecky

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



On Thu, 13 Dec 2001, Matt Long wrote:

 > Glen, Jacek, et. al.,
 >
 > We support them 100%, p-t-a and sparse array.
 >
 > In seems to me that many do not want the pain of dealing with the issue.
 > This is making the spec conform to implementations as opposed to conforming
 > implementations to the spec, IMO.
 >
 > I'd like to see responses that clearly define why p-t-a and sparse array is
 > a bad idea in the context of architecture and not implementation.
 >
 > -Matt Long
 > Phalanx Systems, LLC
 >
 >
 > > -----Original Message-----
 > > From: Glen Daniels [mailto:gdaniels@macromedia.com]
 > > Sent: Thursday, December 13, 2001 10:45 AM
 > > To: 'soapbuilders@groups.yahoo.com'; 'SOAP@discuss.develop.com';
 > > 'axis-dev@xml.apache.org'; 'soap-dev@xml.apache.org'
 > > Subject: [soapbuilders] FEEDBACK REQUESTED - Issues regarding Array
 > > encoding for SOAP 1.2
 > >
 > >
 > >
 > > [If you reply to this, please do so on xml-dist-app@w3.org]
 > >
 > > Hi folks!
 > >
 > > The XML Protocol WG would like to solicit some feedback with
 > > regard to array
 > > encoding.  The particular issues (from our issues list) related
 > > to this are
 > > #s 144 [1] and 161 [2], with Jacek's latest proposal at [3].  I'll briefly
 > > summarize the issues, and then present our current list of
 > > potential options
 > > in hopes that you who are actually using and implementing this stuff can
 > > help to guide us in making some decisions.
 > >
 > > ISSUE 144 - the basic problem here is that the arrayType element
 > > in SOAP 1.1
 > > blurs several pieces of information (the type of array elements and the
 > > dimensionality/size of the array) into one string which then must be
 > > "micro-parsed" in some fairly complicated ways.  The ensuing
 > > discussion also
 > > questioned the utility of sparse/Partially-Transmitted (P.T.) arrays.
 > >
 > > ISSUE 161 - this is essentially a bad word choice in the spec, where array
 > > members are spec'ed as "independent elements" when in fact they aren't.
 > >
 > > At a recent meeting, we decided that the group liked the bulk of Jacek's
 > > proposal, which solves issue 144 by splitting out the arrayType attribute
 > > into two (arraySize and itemType) and also deals with issue 161 (by
 > > replacing the offending wording).
 > >
 > > The point on which we decided more discussion was required
 > > involved whether
 > > to eliminate sparse arrays entirely.  Essentially some felt that
 > > P.T. arrays
 > > were too complicated for the base spec, and if you wanted to do, for
 > > instance, a sparse update of a large database, you could do it by
 > > sending an
 > > array of offset/value pairs.  Others felt the sparse array use-cases were
 > > compelling and we should definitely leave them in the spec.
 > >
 > > So, the questions to you are these:
 > >
 > > 1) Do you use P.T./sparse arrays currently?  If so, what are the scenarios
 > > (array updates, avoiding sending lots of nulls, etc...)?
 > >
 > > 2) Would it bother you to see them go away in SOAP 1.2?
 > >
 > > Thanks very much in advance for any information you can provide.
 > >
 > > --Glen
 > >
 > > [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x144
 > > [2] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x161
 > > [3] http://lists.w3.org/Archives/Public/xml-dist-app/2001Nov/0186.html
 > >
 > > ------------------------ Yahoo! Groups Sponsor ---------------------~-->
 > > Tiny Wireless Camera under $80!
 > > Order Now! FREE VCR Commander!
 > > Click Here - Only 1 Day Left!
 > > http://us.click.yahoo.com/75YKVC/7.PDAA/ySSFAA/W6uqlB/TM
 > > ---------------------------------------------------------------------~->
 > >
 > > -----------------------------------------------------------------
 > > This group is a forum for builders of SOAP implementations to
 > > discuss implementation and interoperability issues.  Please stay on-topic.
 > >
 > > To unsubscribe from this group, send an email to:
 > > soapbuilders-unsubscribe@yahoogroups.com
 > >
 > >
 > >
 > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
 > >
 >

Received on Thursday, 13 December 2001 15:16:53 UTC