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

echo Offset arrays w/o offset?

Expand Messages
  • Matt Long
    Is there any reason why this echo response would be considered valid? Thx, -Matt REQUEST String Array Parameter:
    Message 1 of 18 , Nov 17, 2001
      Is there any reason why this echo response would be considered valid?

      Thx,

      -Matt


      REQUEST String Array Parameter:
      <inputStringArray SOAP-ENC:arrayType="xsd:string[13]"
      SOAP-ENC:offset="[11]">
      <item>string 12</item>
      <item>string 13</item>
      </inputStringArray>


      RESPONSE String Array Result:
      <inputStringArrayResponse SOAP-ENC:arrayType="xsd:string[2]">
      <item xsi:type="xsd:string">string 12</item>
      <item xsi:type="xsd:string">string 13</item>
      </inputStringArrayResponse>
    • Paul Kulchenko
      Hi, Matt! ... I don t see any. imho it s invalid as echo response. Best wishes, Paul. ... __________________________________________________ Do You Yahoo!?
      Message 2 of 18 , Nov 17, 2001
        Hi, Matt!

        --- Matt Long <mlong@...> wrote:
        > Is there any reason why this echo response would be considered
        > valid?
        I don't see any. imho it's invalid as echo response.

        Best wishes, Paul.

        > REQUEST String Array Parameter:
        > <inputStringArray SOAP-ENC:arrayType="xsd:string[13]"
        > SOAP-ENC:offset="[11]">
        > <item>string 12</item>
        > <item>string 13</item>
        > </inputStringArray>
        >
        >
        > RESPONSE String Array Result:
        > <inputStringArrayResponse SOAP-ENC:arrayType="xsd:string[2]">
        > <item xsi:type="xsd:string">string 12</item>
        > <item xsi:type="xsd:string">string 13</item>
        > </inputStringArrayResponse>
        >
        >
        > ------------------------ 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!?
        Find the one for you at Yahoo! Personals
        http://personals.yahoo.com
      • Alan Kent
        ... It took me a moment to spot the offset attribute. This relates then to partially transmitted arrays. My recollection of the discussions on this
        Message 3 of 18 , Nov 18, 2001
          On Sat, Nov 17, 2001 at 07:56:18AM -0800, Paul Kulchenko wrote:
          > Hi, Matt!
          >
          > --- Matt Long <mlong@...> wrote:
          > > Is there any reason why this echo response would be considered
          > > valid?
          > I don't see any. imho it's invalid as echo response.
          >
          > Best wishes, Paul.
          >
          > > REQUEST String Array Parameter:
          > > <inputStringArray SOAP-ENC:arrayType="xsd:string[13]"
          > > SOAP-ENC:offset="[11]">

          It took me a moment to spot the 'offset' attribute. This relates then
          to partially transmitted arrays.

          My recollection of the discussions on this previously relating to
          the interop testing was some (all?) people think partially transmitted
          arrays are different to non-partially transmitted arrays (so both
          ends can decide to support or not support them outside the standard).

          But I do not recall a final decision whether the interop arrays
          can or cannot be partial.

          To me its an open issue relating to 'are partially transmitted
          arrays a different type to non-partially transmitted arrays'.

          If its a non-partially transmitted array, should it just ignore
          attributes that are not relevant? Or report errors if it encounters
          any attribute that uses SOAP-ENC which it does not understand? etc.
          Its all a murky mess until partially transmitted arrays are sorted
          out in SOAP.

          Alan
        • Bob Cunnings
          Hello, I decided to run a similar test against the Round 2 endpoints, in which echoStringArray was called with a partially transmitted (but not sparse; only
          Message 4 of 18 , Nov 18, 2001
            Hello,

            I decided to run a similar test against the Round 2 endpoints, in which echoStringArray was called with a partially transmitted (but not sparse; only SOAP-ENC:offset is used) array. Only 2 of them responded as expected, the others fell into 3 groups:

            -- those who faulted
            -- those who returned fully transmitted array with those elements not received in the request sent as "nil".
            -- those who returned fully transmitted array containing only the elements received in the request.

            The WM Test Client "base" group results are updated to reflect these results.

            RC

            > Hi, Matt!
            >
            > --- Matt Long <mlong@...> wrote:
            > > Is there any reason why this echo response would be considered
            > > valid?
            > I don't see any. imho it's invalid as echo response.
            >
            > Best wishes, Paul.
            >
            > > REQUEST String Array Parameter:
            > > <inputStringArray SOAP-ENC:arrayType="xsd:string[13]"
            > > SOAP-ENC:offset="[11]">
            > > <item>string 12</item>
            > > <item>string 13</item>
            > > </inputStringArray>
            > >
            > >
            > > RESPONSE String Array Result:
            > > <inputStringArrayResponse SOAP-ENC:arrayType="xsd:string[2]">
            > > <item xsi:type="xsd:string">string 12</item>
            > > <item xsi:type="xsd:string">string 13</item>
            > > </inputStringArrayResponse>
            > >
            > >
            > > ------------------------ 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!?
            > Find the one for you at Yahoo! Personals
            > http://personals.yahoo.com
            >
            >
            > -----------------------------------------------------------------
            > 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/
            >
            >
            >
          • Paul Kulchenko
            Hi, Bob! ... why do you think that s wrong? I would agree that part-transm-array (p-t-a) is not exactly the same as full array with first elements set to null,
            Message 5 of 18 , Nov 18, 2001
              Hi, Bob!

              --- Bob Cunnings <cunnings@...> wrote:
              > I decided to run a similar test against the Round 2 endpoints, in
              > which echoStringArray was called with a partially transmitted (but
              > not sparse; only SOAP-ENC:offset is used) array. Only 2 of them
              > responded as expected, the others fell into 3 groups:
              >
              > -- those who faulted
              > -- those who returned fully transmitted array with those elements
              > not received in the request sent as "nil".
              why do you think that's wrong? I would agree that part-transm-array
              (p-t-a) is not exactly the same as full array with first elements set
              to null, but I can't recall any decisions on that. In my case two
              different wire representations have the same language representation.
              Situation is similar to multidimensional array vs. array of array.
              They are different on wire, but you can't distinguish them in
              language representation, so I'll echo former representation using
              later one. I *may* create different representation for p-t-a, but I
              truly don't see any value for that. Am I overlooking something? What
              should be echoed? What is everyone using for representing p-t-a? What
              if I modify a first element? will it downgrade/upgrade it to "usual"
              array? To sparse array?

              Best wishes, Paul.

              > > Hi, Matt!
              > >
              > > --- Matt Long <mlong@...> wrote:
              > > > Is there any reason why this echo response would be considered
              > > > valid?
              > > I don't see any. imho it's invalid as echo response.
              > >
              > > Best wishes, Paul.
              > >
              > > > REQUEST String Array Parameter:
              > > > <inputStringArray SOAP-ENC:arrayType="xsd:string[13]"
              > > > SOAP-ENC:offset="[11]">
              > > > <item>string 12</item>
              > > > <item>string 13</item>
              > > > </inputStringArray>
              > > >
              > > >
              > > > RESPONSE String Array Result:
              > > > <inputStringArrayResponse SOAP-ENC:arrayType="xsd:string[2]">
              > > > <item xsi:type="xsd:string">string 12</item>
              > > > <item xsi:type="xsd:string">string 13</item>
              > > > </inputStringArrayResponse>
              > > >
              > > >
              > > > ------------------------ 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!?
              > > Find the one for you at Yahoo! Personals
              > > http://personals.yahoo.com
              > >
              > >
              > > -----------------------------------------------------------------
              > > 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/
              > >
              > >
              > >
              >
              >
              >
              > ------------------------ 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!?
              Make a great connection at Yahoo! Personals.
              http://personals.yahoo.com
            • Matt Long
              Hi Paul, There are representations of p-t-a that I can interop w/ np. 1) SOAP::Lite transmitted where holes are xsi:nil= 1 2) Spray always transmitted w/
              Message 6 of 18 , Nov 18, 2001
                Hi Paul,

                There are representations of p-t-a that I can interop w/ np.
                1) SOAP::Lite transmitted where "holes" are xsi:nil="1"
                2) Spray always transmitted w/ "position"
                3) Phalanx either transmited w/ "offset" or "position"

                given the request parameter (below) these 3 responses look roughly as
                follows. If the general consensus is that omitted elements are "nil" then
                it would appear that these 3 are identical. Is there any reason why these 3
                responses would not be equivalent serializations???

                Thx,

                -Matt


                REQUEST PARAMETER
                <inputStringArray soapenc:arrayType="xsd:string[3]" soapenc:offset="[2]">
                <item>string 3</item>
                </inputStringArray>

                ~Response (1)
                <return soapenc:arrayType="xsd:string[3]">
                <item xsi:nil="1"/>
                <item xsi:nil="1"/>
                <item>string 3</item>
                </return>

                ~Response (2)
                <return soapenc:arrayType="xsd:string[3]">
                <item soapenc:position="[2]">string 3</item>
                </return>

                ~Response (3)
                <return soapenc:arrayType="xsd:string[3]" soapenc:offset="[2]">
                <item>string 3</item>
                </return>


                > -----Original Message-----
                > From: Paul Kulchenko [mailto:paulclinger@...]
                > Sent: Sunday, November 18, 2001 11:18 PM
                > To: soapbuilders@yahoogroups.com
                > Subject: Re: [soapbuilders] echo Offset arrays w/o offset?
                >
                >
                > Hi, Bob!
                >
                > --- Bob Cunnings <cunnings@...> wrote:
                > > I decided to run a similar test against the Round 2 endpoints, in
                > > which echoStringArray was called with a partially transmitted (but
                > > not sparse; only SOAP-ENC:offset is used) array. Only 2 of them
                > > responded as expected, the others fell into 3 groups:
                > >
                > > -- those who faulted
                > > -- those who returned fully transmitted array with those elements
                > > not received in the request sent as "nil".
                > why do you think that's wrong? I would agree that part-transm-array
                > (p-t-a) is not exactly the same as full array with first elements set
                > to null, but I can't recall any decisions on that. In my case two
                > different wire representations have the same language representation.
                > Situation is similar to multidimensional array vs. array of array.
                > They are different on wire, but you can't distinguish them in
                > language representation, so I'll echo former representation using
                > later one. I *may* create different representation for p-t-a, but I
                > truly don't see any value for that. Am I overlooking something? What
                > should be echoed? What is everyone using for representing p-t-a? What
                > if I modify a first element? will it downgrade/upgrade it to "usual"
                > array? To sparse array?
                >
                > Best wishes, Paul.
                >
                > > > Hi, Matt!
                > > >
                > > > --- Matt Long <mlong@...> wrote:
                > > > > Is there any reason why this echo response would be considered
                > > > > valid?
                > > > I don't see any. imho it's invalid as echo response.
                > > >
                > > > Best wishes, Paul.
                > > >
                > > > > REQUEST String Array Parameter:
                > > > > <inputStringArray SOAP-ENC:arrayType="xsd:string[13]"
                > > > > SOAP-ENC:offset="[11]">
                > > > > <item>string 12</item>
                > > > > <item>string 13</item>
                > > > > </inputStringArray>
                > > > >
                > > > >
                > > > > RESPONSE String Array Result:
                > > > > <inputStringArrayResponse SOAP-ENC:arrayType="xsd:string[2]">
                > > > > <item xsi:type="xsd:string">string 12</item>
                > > > > <item xsi:type="xsd:string">string 13</item>
                > > > > </inputStringArrayResponse>
                > > > >
                > > > >
                > > > > ------------------------ 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!?
                > > > Find the one for you at Yahoo! Personals
                > > > http://personals.yahoo.com
                > > >
                > > >
                > > > -----------------------------------------------------------------
                > > > 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/
                > > >
                > > >
                > > >
                > >
                > >
                > >
                > > ------------------------ 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!?
                > Make a great connection at Yahoo! Personals.
                > http://personals.yahoo.com
                >
                >
                > -----------------------------------------------------------------
                > 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/
                >
              • Bob Cunnings
                Hi Paul, Actually, I m not so sure what s right and what s wrong myself, but your response to Matt s question (below) caused me to start thinking about the
                Message 7 of 18 , Nov 18, 2001
                  Hi Paul,

                  Actually, I'm not so sure what's right and what's wrong myself, but your response to Matt's question (below) caused me to start thinking about the issue again. I was curious about how the more straightforward case involving only SOAP-ENC:offset was handled.

                  What was expected was an p-t-a in the response that looked just like the one in the request in terms of the wire representation, containing no element accessors not present in the request. But that may be too strict, I agree.

                  Believe me, I understand issues involving difficulty in mapping SOAP partial arrays to the language representation used internally (it can, of course, be argued that this is irrelevant as far as the spec is concerned). The solution in which a fully transmitted array with "unknown" members represented as "nil" elements is provided as an alternate encoding for a p-t-a is certainly commonly seen. The pros and cons of this have been discussed at great length on this list, as you know.

                  It's still interesting to look at this from the pov of the test client as an application... it initializes an array with 6 members, all non-nil, and proceeds to send the last 3 elements in the form of a p-t-a to the echo service. The array sent back in the response is compared with the local array, element by element, by position. If the array received contains accessors for all 6 members, with the first 3 "nil", then the comparison fails. In an application where a received array overwriting local data, this type of p-t-a representation could result in trouble.

                  OTH, implementations shouldn't be faulting when receiving a p-t-a, or returning a truncated array as in Matt's original question. AFAIK no one disagrees with that, and a test like this reveals these problems. As for the third case, with missing elements represented by "nil" accessors, I'll label these responses as "PASS" for the time being. Accordingly, the test client has been modified and the results page updated.

                  Thanks,

                  RC


                  > Hi, Bob!
                  >
                  > --- Bob Cunnings <cunnings@...> wrote:
                  > > I decided to run a similar test against the Round 2 endpoints, in
                  > > which echoStringArray was called with a partially transmitted (but
                  > > not sparse; only SOAP-ENC:offset is used) array. Only 2 of them
                  > > responded as expected, the others fell into 3 groups:
                  > >
                  > > -- those who faulted
                  > > -- those who returned fully transmitted array with those elements
                  > > not received in the request sent as "nil".
                  > why do you think that's wrong? I would agree that part-transm-array
                  > (p-t-a) is not exactly the same as full array with first elements set
                  > to null, but I can't recall any decisions on that. In my case two
                  > different wire representations have the same language representation.
                  > Situation is similar to multidimensional array vs. array of array.
                  > They are different on wire, but you can't distinguish them in
                  > language representation, so I'll echo former representation using
                  > later one. I *may* create different representation for p-t-a, but I
                  > truly don't see any value for that. Am I overlooking something? What
                  > should be echoed? What is everyone using for representing p-t-a? What
                  > if I modify a first element? will it downgrade/upgrade it to "usual"
                  > array? To sparse array?
                  >
                  > Best wishes, Paul.
                  >
                  > > > Hi, Matt!
                  > > >
                  > > > --- Matt Long <mlong@...> wrote:
                  > > > > Is there any reason why this echo response would be considered
                  > > > > valid?
                  > > > I don't see any. imho it's invalid as echo response.
                  > > >
                  > > > Best wishes, Paul.
                  > > >
                  > > > > REQUEST String Array Parameter:
                  > > > > <inputStringArray SOAP-ENC:arrayType="xsd:string[13]"
                  > > > > SOAP-ENC:offset="[11]">
                  > > > > <item>string 12</item>
                  > > > > <item>string 13</item>
                  > > > > </inputStringArray>
                  > > > >
                  > > > >
                  > > > > RESPONSE String Array Result:
                  > > > > <inputStringArrayResponse SOAP-ENC:arrayType="xsd:string[2]">
                  > > > > <item xsi:type="xsd:string">string 12</item>
                  > > > > <item xsi:type="xsd:string">string 13</item>
                  > > > > </inputStringArrayResponse>
                  > > > >
                  > > > >
                  > > > > ------------------------ 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!?
                  > > > Find the one for you at Yahoo! Personals
                  > > > http://personals.yahoo.com
                  > > >
                  > > >
                  > > > -----------------------------------------------------------------
                  > > > 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/
                  > > >
                  > > >
                  > > >
                  > >
                  > >
                  > >
                  > > ------------------------ 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!?
                  > Make a great connection at Yahoo! Personals.
                  > http://personals.yahoo.com
                  >
                  >
                  > -----------------------------------------------------------------
                  > 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/
                  >
                  >
                • Bob Cunnings
                  Hi Matt, Thanks for pointing out that some endpoints return an array using position only, which is quite correct. I had forgotten to mention those (like
                  Message 8 of 18 , Nov 19, 2001
                    Hi Matt,

                    Thanks for pointing out that some endpoints return an array using "position" only, which is quite correct. I had forgotten to mention those (like Spray), and the test results were erroneously labeled for them.

                    Another case turned up... ZSI returns this:

                    <return SOAP-ENC:offset="[3]" id="828862c" SOAP-ENC:arrayType="xsd:string[]">
                    <element id="826df18" xsi:type="xsd:string">fourth of six elements</element>
                    <element id="8255110" xsi:type="xsd:string">fifth of six elements</element>
                    <element id="825ef50" xsi:type="xsd:string">sixth of six elements</element>
                    </return>

                    Which I think is ok too.

                    I'm going to leave this alone for a while, and work on the test client to improve its recognition of all these possibilities!

                    Thanks,

                    RC

                    > Hi Paul,
                    >
                    > There are representations of p-t-a that I can interop w/ np.
                    > 1) SOAP::Lite transmitted where "holes" are xsi:nil="1"
                    > 2) Spray always transmitted w/ "position"
                    > 3) Phalanx either transmited w/ "offset" or "position"
                    >
                    > given the request parameter (below) these 3 responses look roughly as
                    > follows. If the general consensus is that omitted elements are "nil" then
                    > it would appear that these 3 are identical. Is there any reason why these 3
                    > responses would not be equivalent serializations???
                    >
                    > Thx,
                    >
                    > -Matt
                    >
                    >
                    > REQUEST PARAMETER
                    > <inputStringArray soapenc:arrayType="xsd:string[3]" soapenc:offset="[2]">
                    > <item>string 3</item>
                    > </inputStringArray>
                    >
                    > ~Response (1)
                    > <return soapenc:arrayType="xsd:string[3]">
                    > <item xsi:nil="1"/>
                    > <item xsi:nil="1"/>
                    > <item>string 3</item>
                    > </return>
                    >
                    > ~Response (2)
                    > <return soapenc:arrayType="xsd:string[3]">
                    > <item soapenc:position="[2]">string 3</item>
                    > </return>
                    >
                    > ~Response (3)
                    > <return soapenc:arrayType="xsd:string[3]" soapenc:offset="[2]">
                    > <item>string 3</item>
                    > </return>
                    >
                    >
                    > > -----Original Message-----
                    > > From: Paul Kulchenko [mailto:paulclinger@...]
                    > > Sent: Sunday, November 18, 2001 11:18 PM
                    > > To: soapbuilders@yahoogroups.com
                    > > Subject: Re: [soapbuilders] echo Offset arrays w/o offset?
                    > >
                    > >
                    > > Hi, Bob!
                    > >
                    > > --- Bob Cunnings <cunnings@...> wrote:
                    > > > I decided to run a similar test against the Round 2 endpoints, in
                    > > > which echoStringArray was called with a partially transmitted (but
                    > > > not sparse; only SOAP-ENC:offset is used) array. Only 2 of them
                    > > > responded as expected, the others fell into 3 groups:
                    > > >
                    > > > -- those who faulted
                    > > > -- those who returned fully transmitted array with those elements
                    > > > not received in the request sent as "nil".
                    > > why do you think that's wrong? I would agree that part-transm-array
                    > > (p-t-a) is not exactly the same as full array with first elements set
                    > > to null, but I can't recall any decisions on that. In my case two
                    > > different wire representations have the same language representation.
                    > > Situation is similar to multidimensional array vs. array of array.
                    > > They are different on wire, but you can't distinguish them in
                    > > language representation, so I'll echo former representation using
                    > > later one. I *may* create different representation for p-t-a, but I
                    > > truly don't see any value for that. Am I overlooking something? What
                    > > should be echoed? What is everyone using for representing p-t-a? What
                    > > if I modify a first element? will it downgrade/upgrade it to "usual"
                    > > array? To sparse array?
                    > >
                    > > Best wishes, Paul.
                    > >
                    > > > > Hi, Matt!
                    > > > >
                    > > > > --- Matt Long <mlong@...> wrote:
                    > > > > > Is there any reason why this echo response would be considered
                    > > > > > valid?
                    > > > > I don't see any. imho it's invalid as echo response.
                    > > > >
                    > > > > Best wishes, Paul.
                    > > > >
                    > > > > > REQUEST String Array Parameter:
                    > > > > > <inputStringArray SOAP-ENC:arrayType="xsd:string[13]"
                    > > > > > SOAP-ENC:offset="[11]">
                    > > > > > <item>string 12</item>
                    > > > > > <item>string 13</item>
                    > > > > > </inputStringArray>
                    > > > > >
                    > > > > >
                    > > > > > RESPONSE String Array Result:
                    > > > > > <inputStringArrayResponse SOAP-ENC:arrayType="xsd:string[2]">
                    > > > > > <item xsi:type="xsd:string">string 12</item>
                    > > > > > <item xsi:type="xsd:string">string 13</item>
                    > > > > > </inputStringArrayResponse>
                    > > > > >
                    > > > > >
                    > > > > > ------------------------ 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!?
                    > > > > Find the one for you at Yahoo! Personals
                    > > > > http://personals.yahoo.com
                    > > > >
                    > > > >
                    > > > > -----------------------------------------------------------------
                    > > > > 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/
                    > > > >
                    > > > >
                    > > > >
                    > > >
                    > > >
                    > > >
                    > > > ------------------------ 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!?
                    > > Make a great connection at Yahoo! Personals.
                    > > http://personals.yahoo.com
                    > >
                    > >
                    > > -----------------------------------------------------------------
                    > > 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
                    oooooo...an offset on an undimensioned array. A value of zero integers indicates that no particular quantity is asserted but that the size may be determined
                    Message 9 of 18 , Nov 19, 2001
                      oooooo...an offset on an undimensioned array.

                      "A value of zero integers indicates that no particular quantity is asserted
                      but that the size may be determined by inspection of the actual members."

                      Clearly, you can determine that the actual array size is [6]. Does anyone
                      object to this ZSI case as being correct?

                      Thx,

                      -Matt


                      > -----Original Message-----
                      > From: Bob Cunnings [mailto:cunnings@...]
                      > Sent: Monday, November 19, 2001 10:13 AM
                      > To: soapbuilders@yahoogroups.com
                      > Subject: Re: [soapbuilders] echo Offset arrays w/o offset?
                      >
                      >
                      > Hi Matt,
                      >
                      > Thanks for pointing out that some endpoints return an array using
                      > "position" only, which is quite correct. I had forgotten to
                      > mention those (like Spray), and the test results were erroneously
                      > labeled for them.
                      >
                      > Another case turned up... ZSI returns this:
                      >
                      > <return SOAP-ENC:offset="[3]" id="828862c"
                      > SOAP-ENC:arrayType="xsd:string[]">
                      > <element id="826df18" xsi:type="xsd:string">fourth of six
                      > elements</element>
                      > <element id="8255110" xsi:type="xsd:string">fifth of six
                      > elements</element>
                      > <element id="825ef50" xsi:type="xsd:string">sixth of six
                      > elements</element>
                      > </return>
                      >
                      > Which I think is ok too.
                      >
                      > I'm going to leave this alone for a while, and work on the test
                      > client to improve its recognition of all these possibilities!
                      >
                      > Thanks,
                      >
                      > RC
                      >
                      > > Hi Paul,
                      > >
                      > > There are representations of p-t-a that I can interop w/ np.
                      > > 1) SOAP::Lite transmitted where "holes" are xsi:nil="1"
                      > > 2) Spray always transmitted w/ "position"
                      > > 3) Phalanx either transmited w/ "offset" or "position"
                      > >
                      > > given the request parameter (below) these 3 responses look roughly as
                      > > follows. If the general consensus is that omitted elements are
                      > "nil" then
                      > > it would appear that these 3 are identical. Is there any
                      > reason why these 3
                      > > responses would not be equivalent serializations???
                      > >
                      > > Thx,
                      > >
                      > > -Matt
                      > >
                      > >
                      > > REQUEST PARAMETER
                      > > <inputStringArray soapenc:arrayType="xsd:string[3]"
                      > soapenc:offset="[2]">
                      > > <item>string 3</item>
                      > > </inputStringArray>
                      > >
                      > > ~Response (1)
                      > > <return soapenc:arrayType="xsd:string[3]">
                      > > <item xsi:nil="1"/>
                      > > <item xsi:nil="1"/>
                      > > <item>string 3</item>
                      > > </return>
                      > >
                      > > ~Response (2)
                      > > <return soapenc:arrayType="xsd:string[3]">
                      > > <item soapenc:position="[2]">string 3</item>
                      > > </return>
                      > >
                      > > ~Response (3)
                      > > <return soapenc:arrayType="xsd:string[3]" soapenc:offset="[2]">
                      > > <item>string 3</item>
                      > > </return>
                      > >
                      > >
                      > > > -----Original Message-----
                      > > > From: Paul Kulchenko [mailto:paulclinger@...]
                      > > > Sent: Sunday, November 18, 2001 11:18 PM
                      > > > To: soapbuilders@yahoogroups.com
                      > > > Subject: Re: [soapbuilders] echo Offset arrays w/o offset?
                      > > >
                      > > >
                      > > > Hi, Bob!
                      > > >
                      > > > --- Bob Cunnings <cunnings@...> wrote:
                      > > > > I decided to run a similar test against the Round 2 endpoints, in
                      > > > > which echoStringArray was called with a partially transmitted (but
                      > > > > not sparse; only SOAP-ENC:offset is used) array. Only 2 of them
                      > > > > responded as expected, the others fell into 3 groups:
                      > > > >
                      > > > > -- those who faulted
                      > > > > -- those who returned fully transmitted array with those elements
                      > > > > not received in the request sent as "nil".
                      > > > why do you think that's wrong? I would agree that part-transm-array
                      > > > (p-t-a) is not exactly the same as full array with first elements set
                      > > > to null, but I can't recall any decisions on that. In my case two
                      > > > different wire representations have the same language representation.
                      > > > Situation is similar to multidimensional array vs. array of array.
                      > > > They are different on wire, but you can't distinguish them in
                      > > > language representation, so I'll echo former representation using
                      > > > later one. I *may* create different representation for p-t-a, but I
                      > > > truly don't see any value for that. Am I overlooking something? What
                      > > > should be echoed? What is everyone using for representing p-t-a? What
                      > > > if I modify a first element? will it downgrade/upgrade it to "usual"
                      > > > array? To sparse array?
                      > > >
                      > > > Best wishes, Paul.
                      > > >
                      > > > > > Hi, Matt!
                      > > > > >
                      > > > > > --- Matt Long <mlong@...> wrote:
                      > > > > > > Is there any reason why this echo response would be considered
                      > > > > > > valid?
                      > > > > > I don't see any. imho it's invalid as echo response.
                      > > > > >
                      > > > > > Best wishes, Paul.
                      > > > > >
                      > > > > > > REQUEST String Array Parameter:
                      > > > > > > <inputStringArray SOAP-ENC:arrayType="xsd:string[13]"
                      > > > > > > SOAP-ENC:offset="[11]">
                      > > > > > > <item>string 12</item>
                      > > > > > > <item>string 13</item>
                      > > > > > > </inputStringArray>
                      > > > > > >
                      > > > > > >
                      > > > > > > RESPONSE String Array Result:
                      > > > > > > <inputStringArrayResponse SOAP-ENC:arrayType="xsd:string[2]">
                      > > > > > > <item xsi:type="xsd:string">string 12</item>
                      > > > > > > <item xsi:type="xsd:string">string 13</item>
                      > > > > > > </inputStringArrayResponse>
                      > > > > > >
                      > > > > > >
                      > > > > > > ------------------------ 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!?
                      > > > > > Find the one for you at Yahoo! Personals
                      > > > > > http://personals.yahoo.com
                      > > > > >
                      > > > > >
                      > > > > > -----------------------------------------------------------------
                      > > > > > 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/
                      > > > > >
                      > > > > >
                      > > > > >
                      > > > >
                      > > > >
                      > > > >
                      > > > > ------------------------ 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!?
                      > > > Make a great connection at Yahoo! Personals.
                      > > > http://personals.yahoo.com
                      > > >
                      > > >
                      > > > -----------------------------------------------------------------
                      > > > 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/
                      >
                    • Alan Kent
                      ... So much has been said that its all getting blury. But I certainly remember someone claim that the fact whether an array can be p-t-a or not can be defined
                      Message 10 of 18 , Nov 19, 2001
                        > OTH, implementations shouldn't be faulting when receiving a p-t-a, or
                        > returning a truncated array as in Matt's original question. AFAIK no
                        > one disagrees with that, and a test like this reveals these problems.

                        So much has been said that its all getting blury. But I certainly
                        remember someone claim that the fact whether an array can be
                        p-t-a or not can be defined and agreed to outside of SOAP.
                        That is a server is permitted to say 'this array must never be p-t-a'.
                        But on the wire SOAP does not encode it differently, and a WSDL file
                        does not allow you to define it differently. In fact I am still
                        confused how to define arrays correctly in WSDL files - it seems
                        to be still flip-flopping around at the moment.

                        But the bottom line certainly I have heard the position that a
                        server *is* permitted to fault when receiveing a p-t-a.
                        The SOAP interop test have never agreed whether arrays
                        can be p-t-a or not. I thought it was an outstanding issue.

                        Personally I see this as a reason why p-t-a or not should be
                        specified in a WSDL file. I am still a strong advocate of either
                        removing p-t-a from SOAP (let people use XML schema to specify it), or
                        failing that someone distinguishing it as a separate type to normal
                        arrays (no position or offset). Eg: SOAP-ENC:Array ->
                        SOAP-ENC:PartialArray or add another attribute. The amount of
                        additional code required to do offset/position processing is
                        significant. And then what are the semantics of the omitted elements?
                        SOAP does not say. The result is interoperability goes down. I think
                        most feel omitted values should be NIL, mainly because it simplifies
                        implementation. But what if an array is declared as not allowing NIL
                        values in it (due to the schema definition)? etc.

                        Its a mess. I hope it gets cleaned up soon. I have done a lot of
                        work with another protocol (Z39.50) where there are so many options
                        and different ways of doing things that interoperability becomes
                        a real struggle. SOAP is already much better. Tightning up a few
                        areas (omitted accessors = NIL? p-t-a as separate type? nillable
                        parts defined in WSDL?) would make SOAP a good, tight, interoperable
                        spec.

                        Alan
                      • Rich Salz
                        I ve been one of the most vocal p-t-a self-described experts so let me chime in here. I ve said, repeatedly, that *sparse arrays* are an inter-application
                        Message 11 of 18 , Nov 19, 2001
                          I've been one of the most vocal p-t-a self-described "experts" so let me
                          chime in here.

                          I've said, repeatedly, that *sparse arrays* are an inter-application
                          matter, and two sides can communicate with their SOAP layer that a
                          particular array has sparse updates, as a communication efficiency. I
                          did *not* intend to generalize that to all p-t-a's (which would be,
                          e.g., the offset attribute). In fact, the 1.1 spec separates sparse
                          from p-t-a, sec 5.4.2.2 vs 5.4.2.1. (Jacek, I forget if your 1.2
                          proposal merges both sparse and offset/position into p-t-a; I hope it
                          doesn't.)

                          It's unfortunate that the spec introduced a new term; they should have
                          just used the term "varying."

                          In fact, I went back and looked at the technology source -- the DCE RPC
                          spec. The offset attribute clearly comes from the IDL "first_is"
                          attribute. According to [1] (you have to do free registration to read
                          the spec online):
                          The first_is attribute is used to define the lower index bounds
                          for significant elements in each dimension of an array. Each <attr_var>
                          in a first_is clause indicates the lowest index, in a given dimension,
                          whose element value is significant both to the caller and the callee.
                          Elements in a given dimension with indexes lower than the dimension's
                          <attr_var> are not meaningful to caller and callee.

                          Take a note of that last sentence.

                          Not surprisingly, the MSDN description [2] leads to some similar data.

                          Whew. Where does this lead us? We need one more piece of data: what
                          does SOAP say about non-transmitted elements? Sigh, read Section 5.5 of
                          the SOAP spec [3], which says
                          An omitted accessor element implies either a default value or that
                          no value is known. The specifics depend on the accessor, method,
                          and its context.

                          Which could be turned into: "i don't know, or i don't care, or insert
                          appropriate value of zero here." It's unfortunate that all three
                          meanings are encoded under the same concept -- omitted element or "nil"
                          element -- but *that's really okay.* Context -- *the application
                          program context* -- will determine which meaning holds. SOAP is a wire
                          protocol, so it's not surprising that it re-uses a construct to handle
                          three non-overlapping cases.

                          This REALLY leads me to conclude that varying/p-t-a arrays MUST be the
                          same as sparse -- an application-level optimization, or other app-level
                          semantic. WSDL only describes syntax, not semantics, so it is not
                          appropriate there, no more than an "idempotent" attribute would be.

                          In the context of the interop tests, what should we do? The absence of
                          semantics for the echoArray tests are a problem with the tests, not with
                          soap. With some minor exceptions (strings and the confusing root
                          attribute), once you have a complete data description, SOAP really only
                          ever gives you one way to encode your data. Our tests don't have
                          complete data descriptions, so folks are surprised, e.g., when ZSI uses
                          offset to skip elements -- the "I don't know/care" approach -- while
                          others use nil -- the "appropriate value of zero" approach.

                          Back in September I posted a brief definition of a test that would be
                          appropriate for sparse and offset/position arrays [4]. Perhaps it's
                          time to look at this again?

                          Hope this helps.
                          /r$

                          [1]
                          http://www.opengroup.org/onlinepubs/009629399/chap4.htm#tagcjh_08_02_18_05
                          [2]
                          http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/ov-featr_50z7.asp
                          [3] http://www.w3.org/TR/SOAP/#_Toc478383525
                          [4] http://groups.yahoo.com/group/soapbuilders/message/5151
                          --
                          Zolera Systems, Securing web services (XML, SOAP, Signatures,
                          Encryption)
                          http://www.zolera.com
                        • Matt Long
                          Hi Alan, ... Think it s a good time to claim, if you don t understand it, then fault rule. ... But that s not Section 5 for echoArray testing,
                          Message 12 of 18 , Nov 19, 2001
                            Hi Alan,

                            <inline>

                            > > OTH, implementations shouldn't be faulting when receiving a p-t-a, or
                            > > returning a truncated array as in Matt's original question. AFAIK no
                            > > one disagrees with that, and a test like this reveals these problems.

                            Think it's a good time to claim, "if you don't understand it, then fault"
                            rule.

                            >
                            > So much has been said that its all getting blury. But I certainly
                            > remember someone claim that the fact whether an array can be
                            > p-t-a or not can be defined and agreed to outside of SOAP.

                            But that's not Section 5 for "echoArray" testing, imo.

                            > That is a server is permitted to say 'this array must never be p-t-a'.
                            No, but the method is capable of faulting on it as the data may be invalid!
                            ;-)

                            > But on the wire SOAP does not encode it differently, and a WSDL file
                            > does not allow you to define it differently. In fact I am still
                            > confused how to define arrays correctly in WSDL files - it seems
                            > to be still flip-flopping around at the moment.

                            >
                            > But the bottom line certainly I have heard the position that a
                            > server *is* permitted to fault when receiveing a p-t-a.
                            > The SOAP interop test have never agreed whether arrays
                            > can be p-t-a or not. I thought it was an outstanding issue.

                            Maybe I'm in error, but I thought the point was to interop Sec 7 and Sec 5
                            encoding.

                            > Alan
                            >
                          • Bob Cunnings
                            Hello, I agree that the specification for the interop testing is lacking here. How about defining new tests, perhaps: -- echoStringArrayPartial --
                            Message 13 of 18 , Nov 19, 2001
                              Hello,

                              I agree that the specification for the interop testing is lacking here.
                              How about defining new tests, perhaps:

                              -- echoStringArrayPartial
                              -- echoStringArraySparse

                              The specification for the test would set forth any assumptions on
                              which it is founded.

                              For the "partial" case, how about something like this: The sender transmits an array and an offset, and the receiver responds with a partial array starting at that offset.

                              For the "sparse" case, the sender transmits an array and a list of positions, and the receiver returns a sparse array containing only those elements specified. Alternatively, an array of strings can be sent along with a search string could be sent, and the return would be a sparse array containing only those elements in which the search string was found.

                              These are terribly contrived, there are many other possibilities. The main point is that the entire source array is transmitted in the request, ensuring that both parties know the values of all elements as well as the array size, as a simplification. At the application level, it would be understood that the return array contained only a
                              subset of the elements in the source array as a efficiency measure.

                              In this way testing for these two array types is isolated in specialized cases. Of course it is not symmetric, as only the sender must deserialize the p-t-a, and only the receiver must serialize a p-t-a onto the wire. To correct this complementary tests might be defined as suggested by Rich, involving sending a partial array in the request along with a default value and an offset (or list of positions), with the server expected to return a new, complete array composed of the elements specified in the request. (I think that's what he meant).

                              Ideas?

                              RC

                              > I've been one of the most vocal p-t-a self-described "experts" so let me
                              > chime in here.
                              >
                              > I've said, repeatedly, that *sparse arrays* are an inter-application
                              > matter, and two sides can communicate with their SOAP layer that a
                              > particular array has sparse updates, as a communication efficiency. I
                              > did *not* intend to generalize that to all p-t-a's (which would be,
                              > e.g., the offset attribute). In fact, the 1.1 spec separates sparse
                              > from p-t-a, sec 5.4.2.2 vs 5.4.2.1. (Jacek, I forget if your 1.2
                              > proposal merges both sparse and offset/position into p-t-a; I hope it
                              > doesn't.)
                              >
                              > It's unfortunate that the spec introduced a new term; they should have
                              > just used the term "varying."
                              >
                              > In fact, I went back and looked at the technology source -- the DCE RPC
                              > spec. The offset attribute clearly comes from the IDL "first_is"
                              > attribute. According to [1] (you have to do free registration to read
                              > the spec online):
                              > The first_is attribute is used to define the lower index bounds
                              > for significant elements in each dimension of an array. Each <attr_var>
                              > in a first_is clause indicates the lowest index, in a given dimension,
                              > whose element value is significant both to the caller and the callee.
                              > Elements in a given dimension with indexes lower than the dimension's
                              > <attr_var> are not meaningful to caller and callee.
                              >
                              > Take a note of that last sentence.
                              >
                              > Not surprisingly, the MSDN description [2] leads to some similar data.
                              >
                              > Whew. Where does this lead us? We need one more piece of data: what
                              > does SOAP say about non-transmitted elements? Sigh, read Section 5.5 of
                              > the SOAP spec [3], which says
                              > An omitted accessor element implies either a default value or that
                              > no value is known. The specifics depend on the accessor, method,
                              > and its context.
                              >
                              > Which could be turned into: "i don't know, or i don't care, or insert
                              > appropriate value of zero here." It's unfortunate that all three
                              > meanings are encoded under the same concept -- omitted element or "nil"
                              > element -- but *that's really okay.* Context -- *the application
                              > program context* -- will determine which meaning holds. SOAP is a wire
                              > protocol, so it's not surprising that it re-uses a construct to handle
                              > three non-overlapping cases.
                              >
                              > This REALLY leads me to conclude that varying/p-t-a arrays MUST be the
                              > same as sparse -- an application-level optimization, or other app-level
                              > semantic. WSDL only describes syntax, not semantics, so it is not
                              > appropriate there, no more than an "idempotent" attribute would be.
                              >
                              > In the context of the interop tests, what should we do? The absence of
                              > semantics for the echoArray tests are a problem with the tests, not with
                              > soap. With some minor exceptions (strings and the confusing root
                              > attribute), once you have a complete data description, SOAP really only
                              > ever gives you one way to encode your data. Our tests don't have
                              > complete data descriptions, so folks are surprised, e.g., when ZSI uses
                              > offset to skip elements -- the "I don't know/care" approach -- while
                              > others use nil -- the "appropriate value of zero" approach.
                              >
                              > Back in September I posted a brief definition of a test that would be
                              > appropriate for sparse and offset/position arrays [4]. Perhaps it's
                              > time to look at this again?
                              >
                              > Hope this helps.
                              > /r$
                              >
                              > [1]
                              > http://www.opengroup.org/onlinepubs/009629399/chap4.htm#tagcjh_08_02_18_05
                              > [2]
                              > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/ov-featr_50z7.asp
                              > [3] http://www.w3.org/TR/SOAP/#_Toc478383525
                              > [4] http://groups.yahoo.com/group/soapbuilders/message/5151
                              > --
                              > Zolera Systems, Securing web services (XML, SOAP, Signatures,
                              > Encryption)
                              > http://www.zolera.com
                              >
                              >
                              > -----------------------------------------------------------------
                              > This group is a forum for builders of SOAP implementations to discuss implementation and interope
                              rability 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
                              I believe the most common use of sparse arrays will be where each side shares a huge data structure and only want to communicate updates. Think distributed
                              Message 14 of 18 , Nov 19, 2001
                                I believe the most common use of sparse arrays will be where each side
                                shares a "huge" data structure and only want to communicate updates.
                                Think distributed mandelbrot, double-buffered videoframe capture :),
                                etc.

                                That's not disagreeing with you, just pointing out another example, one
                                the current tests don't catch.
                                /r$
                                --
                                Zolera Systems, Securing web services (XML, SOAP, Signatures,
                                Encryption)
                                http://www.zolera.com
                              • Paul Kulchenko
                                Hi, Matt! I would postpone any discussions and tests development until we become familiar with latest proposal on array encoding issues [1]. Summary of the
                                Message 15 of 18 , Nov 19, 2001
                                  Hi, Matt!

                                  I would postpone any discussions and tests development until we
                                  become familiar with latest proposal on array encoding issues [1].

                                  Summary of the changes in this update:
                                  1) removed the term "sparse array" because of its clear
                                  mathematical connotations that are inappropriate here
                                  2) clarified that member element names needn't be the same for
                                  all the members of one array, pointed to section 4.1 rule #2
                                  3) updated second paragraph of 4.4.2 to show a better pair of
                                  examples of subtyping enc:Array.
                                  4) added a paragraph to 4.4.2.1 stating that the meaning of
                                  untransmitted members in partially transmitted arrays is
                                  application and implementation specific.

                                  Best wishes, Paul.

                                  [1]
                                  http://lists.w3.org/Archives/Public/xml-dist-app/2001Nov/0186.html

                                  --- Matt Long <mlong@...> wrote:
                                  > I agree that is the most common use case. The generic use case is
                                  > an array
                                  > where the population is unknown and/or varying, inwhich p-t-a
                                  > provides for
                                  > an efficiency, albeit rare very useful and very Section 5.
                                  >
                                  > Thx,
                                  >
                                  > -Matt
                                  >
                                  >
                                  >
                                  > > -----Original Message-----
                                  > > From: Rich Salz [mailto:rsalz@...]
                                  > > Sent: Monday, November 19, 2001 9:08 PM
                                  > > To: Matt Long
                                  > > Cc: soapbuilders@yahoogroups.com
                                  > > Subject: Re: [soapbuilders] echo Offset arrays w/o offset?
                                  > >
                                  > >
                                  > > I believe the most common use of sparse arrays will be where each
                                  > side
                                  > > shares a "huge" data structure and only want to communicate
                                  > updates.
                                  > > Think distributed mandelbrot, double-buffered videoframe capture
                                  > :),
                                  > > etc.
                                  > >
                                  > > That's not disagreeing with you, just pointing out another
                                  > example, one
                                  > > the current tests don't catch.
                                  > > /r$
                                  > > --
                                  > > Zolera Systems, Securing web services (XML, SOAP, Signatures,
                                  > > Encryption)
                                  > > http://www.zolera.com
                                  > >
                                  > >
                                  > > -----------------------------------------------------------------
                                  > > 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/
                                  > >
                                  >
                                  >
                                  > ------------------------ 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!?
                                  Make a great connection at Yahoo! Personals.
                                  http://personals.yahoo.com
                                • Matt Long
                                  Hi Rich, ... tests, not with ... Surely an array can be nil , p-t-a , and fully-transmitted in a single use case. The opinion of some to sub-case p-t-a is
                                  Message 16 of 18 , Nov 19, 2001
                                    Hi Rich,


                                    > The absence of semantics for the echoArray tests are a problem with the
                                    tests, not with
                                    > soap.

                                    Surely an array can be "nil", "p-t-a", and "fully-transmitted" in a single
                                    use case. The opinion of some to sub-case p-t-a is not grounded in spec and
                                    eliminates the aforementioned condition, which can be valuable. IMO, the
                                    echoArray tests are valuable from this perspective and has value on both
                                    sides on the wire.

                                    The argument that I have seen regarding sub-casing p-t-a is an inefficiency.
                                    But, I would argue that any inefficiency avoided is effectively passed
                                    downstream.

                                    Examples:
                                    1) processor populates p-t-a "holes" with nil.
                                    a) single pass for processor
                                    1) potentially large copy on the wire
                                    b) client must loop entire array
                                    2) processor sends "position" for each non-nil element
                                    a) single pass for processor
                                    1) smaller copy of wire than previous
                                    b) client has partial loop on array
                                    3) processor sends "position" OR "offset" for each non-nil element
                                    a) double pass for processor
                                    1) smallest copy on wire
                                    b) client can make most efficient pass on array


                                    To summarize:
                                    It's not feasible to sub-case p-t-a for all cases, e.g., they cannot be
                                    sub-cased and Sec 5 makes no admendment for this.
                                    Partially transmitted arrays can manufacture an efficiency for receiver of
                                    p-t-a, but at a nomial performance cost to sender of a p-t-a.
                                    echoArray tests should be sufficient to test all cases for interop.

                                    Thx,

                                    -Matt
                                  • Alan Kent
                                    ... I just posted a long rave (I get carried away at times) proposing that omitted values be identical to nil values. I argue that protocol implementations
                                    Message 17 of 18 , Nov 19, 2001
                                      On Mon, Nov 19, 2001 at 07:40:31PM -0800, Paul Kulchenko wrote:
                                      > 4) added a paragraph to 4.4.2.1 stating that the meaning of
                                      > untransmitted members in partially transmitted arrays is
                                      > application and implementation specific.

                                      I just posted a long rave (I get carried away at times) proposing
                                      that omitted values be identical to nil values.

                                      I argue that protocol implementations should not (for interoperability
                                      reasons) be allowed to choose semantics. I think semantics should purely
                                      be in the application domain. So either array slots *are* 3 valued
                                      (omitted, null, valid value) or 2 valued (null or valid value).
                                      I think 2 valued is better. The current proposal allows either
                                      which will harm interoperability.

                                      Alan
                                    • Matt Long
                                      I agree that is the most common use case. The generic use case is an array where the population is unknown and/or varying, inwhich p-t-a provides for an
                                      Message 18 of 18 , Nov 19, 2001
                                        I agree that is the most common use case. The generic use case is an array
                                        where the population is unknown and/or varying, inwhich p-t-a provides for
                                        an efficiency, albeit rare very useful and very Section 5.

                                        Thx,

                                        -Matt



                                        > -----Original Message-----
                                        > From: Rich Salz [mailto:rsalz@...]
                                        > Sent: Monday, November 19, 2001 9:08 PM
                                        > To: Matt Long
                                        > Cc: soapbuilders@yahoogroups.com
                                        > Subject: Re: [soapbuilders] echo Offset arrays w/o offset?
                                        >
                                        >
                                        > I believe the most common use of sparse arrays will be where each side
                                        > shares a "huge" data structure and only want to communicate updates.
                                        > Think distributed mandelbrot, double-buffered videoframe capture :),
                                        > etc.
                                        >
                                        > That's not disagreeing with you, just pointing out another example, one
                                        > the current tests don't catch.
                                        > /r$
                                        > --
                                        > Zolera Systems, Securing web services (XML, SOAP, Signatures,
                                        > Encryption)
                                        > http://www.zolera.com
                                        >
                                        >
                                        > -----------------------------------------------------------------
                                        > 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.