Loading ...
Sorry, an error occurred while loading the content.

5430RE: [soapbuilders] Sparse Array w/ Duplicates

Expand Messages
  • Jacek Kopecky
    Oct 1, 2001
    • 0 Attachment
      Matt,
      I think that the basic non-political reason for _not_changing_
      the behavior in such clearly erroneous cases is that it adds
      (possibly non-trivial) logic to the implementation.
      Some solutions, for example not allowing lower position
      following a higher one, are IMHO clearly wrong because they
      disallow cases which aren't clearly erroneous and which the spec
      doesn't forbid.
      Yes, this list does help solving exactly such problems, but here
      I argue that the interop effort for erroneous sparse arrays is
      unneeded and the energy should be spent on better stuff.
      Best regards,

      Jacek Kopecky

      Idoox
      http://www.idoox.com/



      On Mon, 1 Oct 2001, Matt Long wrote:

      > Jacek,
      >
      > My issue w/ (3) is that it embraces a level of dis-interoperability.
      >
      > 1) is there some basic (non-political) reason we cannot agree on some basic
      > rules to implement on the issue?
      > 2) isn't that one of the reasons for this list?
      >
      > If ppl are unwilling to update/alter/change their implementations, so-be-it.
      > I don't see why the rest can't move forward by consensus on some of the more
      > granular issues.
      >
      > -Matt
      >
      >
      > > -----Original Message-----
      > > From: Jacek Kopecky [mailto:jacek@...]
      > > Sent: Monday, October 01, 2001 6:45 AM
      > > To: soapbuilders@yahoogroups.com
      > > Subject: RE: [soapbuilders] Sparse Array w/ Duplicates
      > >
      > >
      > > Matt, others,
      > > I don't think we want to be necessarily interoperable even in
      > > clearly semantically erroneous message cases.
      > > IMO the third choice is the best from the viewpoint of SOAP/1.1
      > > spec. If you're asking about what algorithm to actually
      > > implement, I'd suggest the easiest - don't care. If you do care,
      > > you should fault in such cases.
      > > I think the encoding section should be clearer about sparse
      > > array rules, and I hope we in the XMLP Working Group will address
      > > this issue. Encodings are still a mainly unaddressed area of the
      > > spec.
      > > Best regards
      > >
      > > Jacek Kopecky
      > >
      > > Idoox
      > > http://www.idoox.com/
      > >
      > >
      > >
      > > On Sun, 30 Sep 2001, Matt Long wrote:
      > >
      > > > Hi Paul,
      > > >
      > > > I think your reasoning is certainly logical. The biggest
      > > issue to me is
      > > > interop, i.e., (1), (2), (3) behaviors are only
      > > interoperable between
      > > > implementations in the own subset. The truffle to rout
      > > out is which one
      > > > would be best for "leveled" interop playing field. Since
      > > the spec does not
      > > > address this issue, it would be in the interests of the
      > > community to come a
      > > > bipartisan architectural consensus. My point is that
      > > interoperability is
      > > > should be as granular as possible given the technical and political
      > > > environments.
      > > >
      > > > Opinions, comments, etc.
      > > >
      > > > Thx,
      > > >
      > > > -Matt
      > > >
      > > >
      > > >
      > > > > -----Original Message-----
      > > > > From: Paul Kulchenko [mailto:paulclinger@...]
      > > > > Sent: Sunday, September 30, 2001 4:21 PM
      > > > > To: soapbuilders@yahoogroups.com
      > > > > Subject: Re: [soapbuilders] Sparse Array w/ Duplicates
      > > > >
      > > > >
      > > > > Hi, Matt!
      > > > >
      > > > > > I would believe either of two would apply
      > > > > > 1) a fault
      > > > > > 2) the highest ordinal member of the soap array with a matching
      > > > > 3) unspecified. Implementation dependent.
      > > > > 4) randomly choosed element should be applied according
      > > to algorithm
      > > > > specified in Appendix Z for SOAP specification ;)
      > > > >
      > > > > I would say (2) or (3). It might also be (1), but it may require
      > > > > additional processing depending on your implementation.
      > > > >
      > > > > IMHo rules should be simple:
      > > > >
      > > > > 1. combination of offset(on array)/position(on item) is
      > > not allowed
      > > > > 2. all items must be marked with position attribute if
      > > any of them is
      > > > > marked. Order and presence of duplicates doesn't matter.
      > > > > 3. fault must be generated if size of deserialized array
      > > is greater
      > > > > than size specified in arrayType (invalid combination of
      > > > > elements+offset, position is too big, and so on).
      > > > >
      > > > > Hope I don't forget something.
      > > > >
      > > > > Best wishes, Paul.
      > > > >
      > > > > --- Matt Long <mlong@...> wrote:
      > > > > > What if a sparse array has duplicates on enc:position
      > > > > >
      > > > > > <someArray enc:arrayType="xsd:string[4]">
      > > > > > <item enc:position="[2]">this</item>
      > > > > > <item enc:position="[2]">is</item>
      > > > > > <item enc:position="[2]">a</item>
      > > > > > <item enc:position="[2]">test</item>
      > > > > > </someArray>
      > > > > >
      > > > > > I would believe either of two would apply
      > > > > > 1) a fault
      > > > > > 2) the highest ordinal member of the soap array with a matching
      > > > > > 'position'
      > > > > > value would be the actual value of the member of the
      > > array, e.g.,
      > > > > > ignoring
      > > > > > any values of lower ordinal members of the soap array
      > > with matching
      > > > > > 'position' values.
      > > > > >
      > > > > > Thoughts, comments, etc.
      > > > > >
      > > > > > btw, only three toolkits do (2).
      > > > > >
      > > > > > Thx,
      > > > > >
      > > > > > -Matt
      > > > > >
      > > > > >
      > > > > >
      > > > > >
      > > > > >
      > > > > >
      > > > > > ------------------------ Yahoo! Groups Sponsor
      > > > > >
      > > > > >
      > > -----------------------------------------------------------------
      > > > > > 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/
      > > > > >
      > > > > >
      > > > >
      > > > >
      > > > > __________________________________________________
      > > > > Do You Yahoo!?
      > > > > Listen to your Yahoo! Mail messages from any phone.
      > > > > http://phone.yahoo.com
      > > > >
      > > > > ------------------------ Yahoo! Groups Sponsor
      > > > > ---------------------~-->
      > > > > Pinpoint the right security solution for your company- Learn
      > > > > how to add 128- bit encryption and to authenticate your web
      > > > > site with VeriSign's FREE guide!
      > > > > http://us.click.yahoo.com/yQix2C/33_CAA/yigFAA/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/
      > > >
      > > >
      > > >
      > > > -----------------------------------------------------------------
      > > > 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/
      > >
      > >
      >
      >
      >
      > -----------------------------------------------------------------
      > 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/
      >
      >
      >
      > -----------------------------------------------------------------
      > 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/
      >
      >
    • Show all 13 messages in this topic