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

5436RE: [soapbuilders] Sparse Array w/ Duplicates

Expand Messages
  • Jacek Kopecky
    Oct 1, 2001
    • 0 Attachment
      Matt,
      Yes it is reasonable because you're effectively saying "let's
      all accept (and some implement) Andrew's logic." This is a clear
      proposal.
      But there can be a different proposal for clarifying these rules
      that would be as reasonable as yours.
      If enough soap builders can accept your proposal and if it's
      documented somewhere in a visible FAQ or something, it will do.
      I'll accept it. (Acting on behalf of myself, not Idoox.)
      Who else? 8-)

      Jacek Kopecky

      Idoox
      http://www.idoox.com/



      On Mon, 1 Oct 2001, Matt Long wrote:

      > 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/
      >
      >
      >
      > -----------------------------------------------------------------
      > 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