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

5429RE: [soapbuilders] Sparse Array w/ Duplicates

Expand Messages
  • Matt Long
    Oct 1, 2001
      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/
    • Show all 13 messages in this topic