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

5434RE: [soapbuilders] Sparse Array w/ Duplicates

Expand Messages
  • Matt Long
    Oct 1, 2001
      Jacek,

      There is room for both (1) and (2) as the (1)s will interop with the (2)s.
      The bigger concern is whether the (2)s will interop with each other. If you
      choose to allow (2), i.e., utilizing Andrew's logic, then you are not
      "breaking", rather adding features/functionality and being interoperable
      with (1)s.

      The issues then become...
      A) MUST fault on mix of "offset" + "position"
      or
      B) MUST implement Andrew's logic for mix of "offset" + "position"

      Does this not seem reasonable???

      -Matt



      > -----Original Message-----
      > From: Jacek Kopecky [mailto:jacek@...]
      > Sent: Monday, October 01, 2001 9:36 AM
      > To: soapbuilders@yahoogroups.com
      > Subject: RE: [soapbuilders] Sparse Array w/ Duplicates
      >
      >
      > Matt,
      > you are right, there remains the more general issue of mixing
      > offset and positions (non-positioned vs. positioned elements).
      > I favor 2), i.e. forbidding the mix.
      > But in case of conflictiong positions, I would go with
      > "implementation-dependent". This clearly indicates that this
      > shouldn't be used. 8-)
      >
      > Jacek Kopecky
      >
      > Idoox
      > http://www.idoox.com/
      >
      >
      >
      > On Mon, 1 Oct 2001, Matt Long wrote:
      >
      > > I reiterate:
      > >
      > > > > 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.
      > >
      > >
      > > imo, the not allowing lower position following higher
      > position is only a
      > > function of whether you allow, i.e., don't fault, a combo
      > of "offset" != 0
      > > and "position". *IF* WE agree that this should be allowed
      > (spec is silent
      > > on this), then we must hammer out the logic for interop
      > purposes. Ignoring
      > > "offset" when array members contain "position" clearly is
      > bogus as the
      > > message intent is also ignored.
      > >
      > > I proposed either:
      > > 1) allow it and use Andrew's logic
      > > 2) ALWAYS fault on the case.
      > >
      > > Example:
      > >
      > > <myArray SOAP-ENC:arrayType="xsd:string[5]" SOAP-ENC:offset="[1]">
      > > <item>this</item>
      > > <item SOAP-ENC:position="[2]">is</item>
      > > <item>a</item>
      > > <item SOAP-ENC:position="[4]">test</item>
      > > </myArray>
      > >
      > >
      > >
      > > > -----Original Message-----
      > > > From: Jacek Kopecky [mailto:jacek@...]
      > > > Sent: Monday, October 01, 2001 8:59 AM
      > > > To: soapbuilders@yahoogroups.com
      > > > Subject: RE: [soapbuilders] Sparse Array w/ Duplicates
      > > >
      > > >
      > > > 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/
      > >
      > >
      >
      >
      >
      > -----------------------------------------------------------------
      > 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