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

RE: [soapbuilders] Sparse Array w/ Duplicates

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.