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

Re: [soapbuilders] Sparse Array w/ Duplicates

Expand Messages
  • David Crowley
    Andrew Layman discussed the algorithim for decoding offset and position attributes in [1]. As for your example: For practical reasons, we should consider it
    Message 1 of 13 , Sep 30, 2001
    • 0 Attachment
      Andrew Layman discussed the algorithim for decoding offset and position
      attributes in [1]. As for your example:

      "For practical reasons, we should consider it an error if
      the encoded position of an element is the same as or prior
      to the position of the previous element."


      I use the algorithim he discuses in [1] because it is very reasonable
      and clears up the ambiguities.

      David


      [1] http://groups.yahoo.com/group/soapbuilders/message/5126

      >
      > 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
      >
    • Jacek Kopecky
      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
      Message 2 of 13 , Oct 1, 2001
      • 0 Attachment
        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/
        >
        >
      • Matt Long
        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
        Message 3 of 13 , Oct 1, 2001
        • 0 Attachment
          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/
        • Jacek Kopecky
          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
          Message 4 of 13 , 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/
            >
            >
          • Matt Long
            ... 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
            Message 5 of 13 , Oct 1, 2001
            • 0 Attachment
              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/
            • Jacek Kopecky
              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
              Message 6 of 13 , Oct 1, 2001
              • 0 Attachment
                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/
                >
                >
              • Rich Salz
                Is it more likely to be a sender BUG or proper behavior if a serialization overwrites elements? How many times, for example, does Perl s keys iterating
                Message 7 of 13 , Oct 1, 2001
                • 0 Attachment
                  Is it more likely to be a sender BUG or proper behavior if a
                  serialization "overwrites" elements?

                  How many times, for example, does Perl's "keys" iterating over a
                  dictionary, or Python's "in" or "items" iterating, or a VisualBasic
                  Enumeration -- how often are they likely to get repeats?

                  Yes, I am sure it is POSSIBLE that some implementation will find it
                  efficient to be able to REPLACE elements. But it is much more likely a
                  bug, and a server is better off rejecting such a message.
                  /r$
                  --
                  Zolera Systems, Your Key to Online Integrity
                  Securing Web services: XML, SOAP, Dig-sig, Encryption
                  http://www.zolera.com
                • Matt Long
                  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
                  Message 8 of 13 , Oct 1, 2001
                  • 0 Attachment
                    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/
                  • Matt Long
                    hi rich, My recollection from the opinion in [1] is that duplicates are not allowed. [1] http://groups.yahoo.com/group/soapbuilders/message/5126 This is not
                    Message 9 of 13 , Oct 1, 2001
                    • 0 Attachment
                      hi rich,

                      My recollection from the opinion in [1] is that duplicates are not allowed.

                      [1] http://groups.yahoo.com/group/soapbuilders/message/5126

                      This is not standardized across the framework, which is an issue that needs
                      to be addressed, imo.
                      A) Allow duplicates
                      B) Fault on duplicates

                      -Matt



                      > -----Original Message-----
                      > From: rsalz@... [mailto:rsalz@...]
                      > Sent: Monday, October 01, 2001 9:44 AM
                      > To: Matt Long
                      > Cc: soapbuilders@yahoogroups.com
                      > Subject: Re: [soapbuilders] Sparse Array w/ Duplicates
                      >
                      >
                      > Is it more likely to be a sender BUG or proper behavior if a
                      > serialization "overwrites" elements?
                      >
                      > How many times, for example, does Perl's "keys" iterating over a
                      > dictionary, or Python's "in" or "items" iterating, or a VisualBasic
                      > Enumeration -- how often are they likely to get repeats?
                      >
                      > Yes, I am sure it is POSSIBLE that some implementation will find it
                      > efficient to be able to REPLACE elements. But it is much
                      > more likely a
                      > bug, and a server is better off rejecting such a message.
                      > /r$
                      > --
                      > Zolera Systems, Your Key to Online Integrity
                      > Securing Web services: XML, SOAP, Dig-sig, Encryption
                      > http://www.zolera.com
                    • Jacek Kopecky
                      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
                      Message 10 of 13 , 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/
                        >
                        >
                      Your message has been successfully submitted and would be delivered to recipients shortly.