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

Re: [soapbuilders] UserLand's interop endpoint up

Expand Messages
  • Rich Salz
    ... Sluggard. :) ... As I said before, the answer is it depends. Since you do a subset of full SOAP, it s quite possible that some other toolkit will send you
    Message 1 of 22 , Nov 10, 2001
      > Jake is taking most of the day off today

      Sluggard. :)

      > What we want is to be able to say to developers: "If you download this
      > toolkit you'll be able to connect your text editor or outliner into our CMS
      > through SOAP 1.1."

      As I said before, the answer is it depends. Since you do a subset of
      full SOAP, it's quite possible that some other toolkit will send you
      messages that you can't parse. You can lessen the problem by defining
      your interface so that the "most obvious" encoding falls into the set
      that you support; for example, no multi-dimensional arrays. As to how
      to define those interfaces, that's up to your implementors.

      But once they're defined, I betcha many folks here would be glad to send
      you sample packets encoded by their toolkits. Then you could make your
      own table just like Sam's. :) But if you want that to happen, then you
      should express your interface in terms of XMLSchema, maybe even WSDL.
      (Once you have schema, going to WSDL is usually trivial.) Prose
      descriptions are not helpful here. You're defining an interface, and
      you need an interface definition language, and XML Schema is,
      pragmatically speaking, the only XML IDL around right now (ALIDL et al
      notwithstanding). Yes it's huge and a pain in the ass, but you can
      probably understand enough of it in a day so that you can write the
      definitions of your interfaces.

      > And the really big question -- is this all you want from us? Or is this the
      > beginning of a slippery slope where I lose Jake on my devteam and have to
      > tell my customers to wait again?

      "We" want nothing. :) YOUR customers will want to interop. It's gonna be
      a set of judgement calls. As you do the "market is a conversation"
      thang with your users, you will find out what sending-side toolkits are
      important to them, and you might have to do some more work.

      You can't remove that fundamental tension: Frontier doesn't implement
      all of SOAP, and the community is not going to limit itself to the BDG
      anymore. So, the question you have to ask yourself is, do you feel
      lucky? Sorry :), I mean, did you implement the RIGHT subset? Probably,
      and in this note I've tried to show a way that folks here might be able
      to help you get a more definitive -- no, pragmatic -- answer.

      /r$
      --
      Zolera Systems, Securing web services (XML, SOAP, Signatures,
      Encryption)
      http://www.zolera.com
    • Dave Winer
      Rich -- a very interesting story. Reminds me of The Paper Chase, where the study group fell apart. So Sam has a table of implementations he interops with, are
      Message 2 of 22 , Nov 10, 2001
        Rich -- a very interesting story.

        Reminds me of The Paper Chase, where the study group fell apart.

        So Sam has a table of implementations he interops with, are there other
        tables floating around?

        Trust me, this was not the initial intent of SOAP. It was supposed to be
        Simple (hence the first letter in the acronym). Interop was supposed to come
        quickly and painlessly. I'm sorry it turned out to be so complex.

        If anyone else has a perspective on what interop means in November 2001, I'm
        very interested in hearing more.

        Dave


        ----- Original Message -----
        From: "Rich Salz" <rsalz@...>
        To: "Dave Winer" <dave@...>
        Cc: <soapbuilders@yahoogroups.com>
        Sent: Saturday, November 10, 2001 10:35 AM
        Subject: Re: [soapbuilders] UserLand's interop endpoint up


        > > Jake is taking most of the day off today
        >
        > Sluggard. :)
        >
        > > What we want is to be able to say to developers: "If you download this
        > > toolkit you'll be able to connect your text editor or outliner into our
        CMS
        > > through SOAP 1.1."
        >
        > As I said before, the answer is it depends. Since you do a subset of
        > full SOAP, it's quite possible that some other toolkit will send you
        > messages that you can't parse. You can lessen the problem by defining
        > your interface so that the "most obvious" encoding falls into the set
        > that you support; for example, no multi-dimensional arrays. As to how
        > to define those interfaces, that's up to your implementors.
        >
        > But once they're defined, I betcha many folks here would be glad to send
        > you sample packets encoded by their toolkits. Then you could make your
        > own table just like Sam's. :) But if you want that to happen, then you
        > should express your interface in terms of XMLSchema, maybe even WSDL.
        > (Once you have schema, going to WSDL is usually trivial.) Prose
        > descriptions are not helpful here. You're defining an interface, and
        > you need an interface definition language, and XML Schema is,
        > pragmatically speaking, the only XML IDL around right now (ALIDL et al
        > notwithstanding). Yes it's huge and a pain in the ass, but you can
        > probably understand enough of it in a day so that you can write the
        > definitions of your interfaces.
        >
        > > And the really big question -- is this all you want from us? Or is this
        the
        > > beginning of a slippery slope where I lose Jake on my devteam and have
        to
        > > tell my customers to wait again?
        >
        > "We" want nothing. :) YOUR customers will want to interop. It's gonna be
        > a set of judgement calls. As you do the "market is a conversation"
        > thang with your users, you will find out what sending-side toolkits are
        > important to them, and you might have to do some more work.
        >
        > You can't remove that fundamental tension: Frontier doesn't implement
        > all of SOAP, and the community is not going to limit itself to the BDG
        > anymore. So, the question you have to ask yourself is, do you feel
        > lucky? Sorry :), I mean, did you implement the RIGHT subset? Probably,
        > and in this note I've tried to show a way that folks here might be able
        > to help you get a more definitive -- no, pragmatic -- answer.
        >
        > /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/
        >
        >
      • Rich Salz
        You seem to still be slightly misunderstanding me. ... No, YOU FELL BEHIND. You don t implement the whole spec. Don t take it personally, I don t either.
        Message 3 of 22 , Nov 10, 2001
          You seem to still be slightly misunderstanding me.

          > Reminds me of The Paper Chase, where the study group fell apart.

          No, YOU FELL BEHIND. You don't implement the whole spec. Don't take it
          personally, I don't either. But don't paint it as anything other than
          this:
          Frontier provides a subset of SOAP, and to the best of our knowledge
          and experience, that subset interoperates with all the major toolkits.

          > So Sam has a table of implementations he interops with, are there
          > other tables floating around?

          My passing reference to Sam's table was a joke. I was trying to say
          that if you're in such a lather about his table, make your own. Isn't
          that part of your DIY philosophy? Sigh. At any rate, I'll try to stop
          making jokes or mark them with a smiley.

          If A implements SOAP1.1 and B implements SOAP1.1 than we expect A and B
          to interoperate. Repeat as needed for the other letters of the
          alphabet. What does "implements SOAP1.1" mean? It means that its
          behavior is defined by the text in that document, but unfortunately that
          document has both bugs and ambiguities. So we need a conformance test,
          a strict algorithmic approach that finds every statement of fact in the
          spec, and prepares sample inputs and expected outputs for those facts.
          Then in combination. Whew, that's a lot of work. It rarely happens.

          So, we settle for pragmatism. We define some test cases that catch the
          common subset and illuminate particularly dark corners, and we try
          pairwise testing. Their is no transitive property, because A=B and C=B
          doesn't imply A=C because B has bugs and ambiguities. In my experience
          it's always been that way (TCP, HTTP, HTML, NFS; DCE RPC came closest,
          but only tested the unauthenticated subset).

          /r$

          --
          Zolera Systems, Securing web services (XML, SOAP, Signatures,
          Encryption)
          http://www.zolera.com
        • Dave Winer
          Hey -- I didn t even know Sam had a table until you told me. Further, re YOU FELL BEHIND : 1. In email, all caps is like yelling at someone face to face. I
          Message 4 of 22 , Nov 10, 2001
            Hey -- I didn't even know Sam had a table until you told me.

            Further, re "YOU FELL BEHIND":

            1. In email, all caps is like yelling at someone face to face. I don't like
            being yelled at, so please don't do it unless you think I'm about to walk in
            front of a bus or something like that.

            2. From your point of view we fell behind. I want to acknowledge that.

            3. I have a different point of view.

            I'm getting back to making software for myself, my team and my customers.

            Dave


            ----- Original Message -----
            From: "Rich Salz" <rsalz@...>
            To: "Dave Winer" <dave@...>
            Cc: <soapbuilders@yahoogroups.com>
            Sent: Saturday, November 10, 2001 11:35 AM
            Subject: Re: [soapbuilders] UserLand's interop endpoint up


            > You seem to still be slightly misunderstanding me.
            >
            > > Reminds me of The Paper Chase, where the study group fell apart.
            >
            > No, YOU FELL BEHIND. You don't implement the whole spec. Don't take it
            > personally, I don't either. But don't paint it as anything other than
            > this:
            > Frontier provides a subset of SOAP, and to the best of our knowledge
            > and experience, that subset interoperates with all the major toolkits.
            >
            > > So Sam has a table of implementations he interops with, are there
            > > other tables floating around?
            >
            > My passing reference to Sam's table was a joke. I was trying to say
            > that if you're in such a lather about his table, make your own. Isn't
            > that part of your DIY philosophy? Sigh. At any rate, I'll try to stop
            > making jokes or mark them with a smiley.
            >
            > If A implements SOAP1.1 and B implements SOAP1.1 than we expect A and B
            > to interoperate. Repeat as needed for the other letters of the
            > alphabet. What does "implements SOAP1.1" mean? It means that its
            > behavior is defined by the text in that document, but unfortunately that
            > document has both bugs and ambiguities. So we need a conformance test,
            > a strict algorithmic approach that finds every statement of fact in the
            > spec, and prepares sample inputs and expected outputs for those facts.
            > Then in combination. Whew, that's a lot of work. It rarely happens.
            >
            > So, we settle for pragmatism. We define some test cases that catch the
            > common subset and illuminate particularly dark corners, and we try
            > pairwise testing. Their is no transitive property, because A=B and C=B
            > doesn't imply A=C because B has bugs and ambiguities. In my experience
            > it's always been that way (TCP, HTTP, HTML, NFS; DCE RPC came closest,
            > but only tested the unauthenticated subset).
            >
            > /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/
            >
            >
          • Rich Salz
            ... No, you mentioned it first, something about some Apache/XML web page Sam maintains that has a list of SOAP implementations. I yelled on purpose.
            Message 5 of 22 , Nov 10, 2001
              > Hey -- I didn't even know Sam had a table until you told me.

              No, you mentioned it first, something about some Apache/XML web page Sam
              maintains that has a list of SOAP implementations.

              I "yelled" on purpose. Because, after nearly a half-dozen interchanges,
              you keep saying things like this:
              > 3. I have a different point of view.

              Whatever, Dave. I'm not even going to ask what your point of view is --
              I don't want to know. I tried to be helpful explaining what the state of
              the world was, how you could improve things for yourself, etc. I hope
              you found it useful. I'll leave this thread now with one last meme
              (sic!): Frontier probably interoperates for those parts of the spec you
              decided to implement.
              /r$
              --
              Zolera Systems, Securing web services (XML, SOAP, Signatures,
              Encryption)
              http://www.zolera.com
            • Simon Fell
              FWIW, i wrote a WSDL description for Manila a while back http://www.pocketsoap.com/interop/manila.wsdl Cheers Simon
              Message 6 of 22 , Nov 10, 2001
                FWIW, i wrote a WSDL description for Manila a while back
                http://www.pocketsoap.com/interop/manila.wsdl

                Cheers
                Simon

                On Sat, 10 Nov 2001 13:35:21 -0500, in soap you wrote:

                >> Jake is taking most of the day off today
                >
                >Sluggard. :)
                >
                >> What we want is to be able to say to developers: "If you download this
                >> toolkit you'll be able to connect your text editor or outliner into our CMS
                >> through SOAP 1.1."
                >
                >As I said before, the answer is it depends. Since you do a subset of
                >full SOAP, it's quite possible that some other toolkit will send you
                >messages that you can't parse. You can lessen the problem by defining
                >your interface so that the "most obvious" encoding falls into the set
                >that you support; for example, no multi-dimensional arrays. As to how
                >to define those interfaces, that's up to your implementors.
                >
                >But once they're defined, I betcha many folks here would be glad to send
                >you sample packets encoded by their toolkits. Then you could make your
                >own table just like Sam's. :) But if you want that to happen, then you
                >should express your interface in terms of XMLSchema, maybe even WSDL.
                >(Once you have schema, going to WSDL is usually trivial.) Prose
                >descriptions are not helpful here. You're defining an interface, and
                >you need an interface definition language, and XML Schema is,
                >pragmatically speaking, the only XML IDL around right now (ALIDL et al
                >notwithstanding). Yes it's huge and a pain in the ass, but you can
                >probably understand enough of it in a day so that you can write the
                >definitions of your interfaces.
                >
                >> And the really big question -- is this all you want from us? Or is this the
                >> beginning of a slippery slope where I lose Jake on my devteam and have to
                >> tell my customers to wait again?
                >
                >"We" want nothing. :) YOUR customers will want to interop. It's gonna be
                >a set of judgement calls. As you do the "market is a conversation"
                >thang with your users, you will find out what sending-side toolkits are
                >important to them, and you might have to do some more work.
                >
                >You can't remove that fundamental tension: Frontier doesn't implement
                >all of SOAP, and the community is not going to limit itself to the BDG
                >anymore. So, the question you have to ask yourself is, do you feel
                >lucky? Sorry :), I mean, did you implement the RIGHT subset? Probably,
                >and in this note I've tried to show a way that folks here might be able
                >to help you get a more definitive -- no, pragmatic -- answer.
                >
                > /r$
              • Dave Winer
                Simon, I added a link to this on the docs page for the Manila interface. http://www.xml-rpc.com/manilaRpcSpec This way no one can miss it. Sorry for not
                Message 7 of 22 , Nov 10, 2001
                  Simon, I added a link to this on the docs page for the Manila interface.

                  http://www.xml-rpc.com/manilaRpcSpec

                  This way no one can miss it. Sorry for not linking it in sooner.

                  Dave


                  ----- Original Message -----
                  From: "Simon Fell" <soap@...>
                  To: <soapbuilders@yahoogroups.com>
                  Sent: Saturday, November 10, 2001 12:26 PM
                  Subject: Re: [soapbuilders] UserLand's interop endpoint up


                  > FWIW, i wrote a WSDL description for Manila a while back
                  > http://www.pocketsoap.com/interop/manila.wsdl
                  >
                  > Cheers
                  > Simon
                  >
                  > On Sat, 10 Nov 2001 13:35:21 -0500, in soap you wrote:
                  >
                  > >> Jake is taking most of the day off today
                  > >
                  > >Sluggard. :)
                  > >
                  > >> What we want is to be able to say to developers: "If you download this
                  > >> toolkit you'll be able to connect your text editor or outliner into our
                  CMS
                  > >> through SOAP 1.1."
                  > >
                  > >As I said before, the answer is it depends. Since you do a subset of
                  > >full SOAP, it's quite possible that some other toolkit will send you
                  > >messages that you can't parse. You can lessen the problem by defining
                  > >your interface so that the "most obvious" encoding falls into the set
                  > >that you support; for example, no multi-dimensional arrays. As to how
                  > >to define those interfaces, that's up to your implementors.
                  > >
                  > >But once they're defined, I betcha many folks here would be glad to send
                  > >you sample packets encoded by their toolkits. Then you could make your
                  > >own table just like Sam's. :) But if you want that to happen, then you
                  > >should express your interface in terms of XMLSchema, maybe even WSDL.
                  > >(Once you have schema, going to WSDL is usually trivial.) Prose
                  > >descriptions are not helpful here. You're defining an interface, and
                  > >you need an interface definition language, and XML Schema is,
                  > >pragmatically speaking, the only XML IDL around right now (ALIDL et al
                  > >notwithstanding). Yes it's huge and a pain in the ass, but you can
                  > >probably understand enough of it in a day so that you can write the
                  > >definitions of your interfaces.
                  > >
                  > >> And the really big question -- is this all you want from us? Or is this
                  the
                  > >> beginning of a slippery slope where I lose Jake on my devteam and have
                  to
                  > >> tell my customers to wait again?
                  > >
                  > >"We" want nothing. :) YOUR customers will want to interop. It's gonna be
                  > >a set of judgement calls. As you do the "market is a conversation"
                  > >thang with your users, you will find out what sending-side toolkits are
                  > >important to them, and you might have to do some more work.
                  > >
                  > >You can't remove that fundamental tension: Frontier doesn't implement
                  > >all of SOAP, and the community is not going to limit itself to the BDG
                  > >anymore. So, the question you have to ask yourself is, do you feel
                  > >lucky? Sorry :), I mean, did you implement the RIGHT subset? Probably,
                  > >and in this note I've tried to show a way that folks here might be able
                  > >to help you get a more definitive -- no, pragmatic -- answer.
                  > >
                  > > /r$
                  >
                  >
                  > -----------------------------------------------------------------
                  > 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/
                  >
                  >
                • Jake Savin
                  ... Hi Sam, I modified the configuration on the Frontier endpoint so that it now supports both SOAPAction values: SOAPAction: http://soapinterop.org/ -or-
                  Message 8 of 22 , Nov 10, 2001
                    on 11/9/01 7:06 PM, Sam Ruby at rubys@... wrote:

                    > Jake Savin wrote:
                    >>
                    >> SOAPAction: urn:soapinterop
                    >
                    > Is there any way that you could update it to match the SOAPAction specified
                    > by http://www.whitemesa.com/interop.htm, i.e., "http://soapinterop.org/" ?
                    >
                    > - Sam Ruby

                    Hi Sam,

                    I modified the configuration on the Frontier endpoint so that it now
                    supports both SOAPAction values:

                    SOAPAction: "http://soapinterop.org/"

                    -or-

                    SOAPAction: "urn:soapinterop"

                    This way clients can test against the Frontier endpoint using the new value,
                    and clients which still use the older value won't break.

                    -Jake
                  • nahi@mwd.biglobe.ne.jp
                    Hi Jake, ... SOAP4R client - Frontier server test results: 21/49 http://www.jin.gr.jp/~nahi/Ruby/SOAP4R/wiki.cgi?
                    Message 9 of 22 , Nov 10, 2001
                      Hi Jake,

                      > I modified the configuration on the Frontier endpoint so that it now
                      > supports both SOAPAction values:
                      >
                      > SOAPAction: "http://soapinterop.org/"
                      >
                      > -or-
                      >
                      > SOAPAction: "urn:soapinterop"

                      SOAP4R client - Frontier server test results: 21/49
                      http://www.jin.gr.jp/~nahi/Ruby/SOAP4R/wiki.cgi?
                      cmd=view;name=InteropResults%3A%3ASOAP4R%2F1.3.8-Frontier

                      Hope this helps,
                      // NaHi
                    • Bob Cunnings
                      Hi Jake, Looks good. The Round 2 endpoint table has been updated. Testing with the WM client discovers that all supported methods in the base group pass
                      Message 10 of 22 , Nov 10, 2001
                        Hi Jake,

                        Looks good. The Round 2 endpoint table has been updated. Testing with the WM client discovers that all supported methods in the "base" group pass except echoStructArray, which returns an incorrect arrayType value:

                        ...<Result SOAP-ENC:arrayType="urn:SOAPStruct[3]" xmlns:urn="http://www.xmethods.com/service" xsi:type="SOAP-ENC:Array">...

                        The SOAPStruct type name is qualified by the wrong namespace... http://soapinterop.org/xsd is expected [1].

                        RC

                        [1] http://www.whitemesa.com/interop/proposal2.html#echoStructArray

                        > on 11/9/01 7:06 PM, Sam Ruby at rubys@... wrote:
                        >
                        > > Jake Savin wrote:
                        > >>
                        > >> SOAPAction: urn:soapinterop
                        > >
                        > > Is there any way that you could update it to match the SOAPAction specified
                        > > by http://www.whitemesa.com/interop.htm, i.e., "http://soapinterop.org/" ?
                        > >
                        > > - Sam Ruby
                        >
                        > Hi Sam,
                        >
                        > I modified the configuration on the Frontier endpoint so that it now
                        > supports both SOAPAction values:
                        >
                        > SOAPAction: "http://soapinterop.org/"
                        >
                        > -or-
                        >
                        > SOAPAction: "urn:soapinterop"
                        >
                        > This way clients can test against the Frontier endpoint using the new value,
                        > and clients which still use the older value won't break.
                        >
                        > -Jake
                        >
                        >
                        >
                        > -----------------------------------------------------------------
                        > 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/
                        >
                        >
                      • Sam Ruby
                        ... Please take a moment to check out http://www.whitemesa.com/interop.htm . It contains three sections. First is a description of the scenarios. In both
                        Message 11 of 22 , Nov 11, 2001
                          Dave Winer wrote:
                          >
                          > So Sam has a table of implementations he interops with, are there other
                          > tables floating around?

                          Please take a moment to check out http://www.whitemesa.com/interop.htm .
                          It contains three sections.

                          First is a description of the scenarios. In both human readable prose
                          and in machine readable formats.

                          Second is a list of active endpoints.

                          Third is a list of published results.

                          In addition to these three sections, at the bottom you can find a pointer
                          to a "competing" registry, a back pointer to the previous effort, and the
                          e-mail address of the maintainter of this page.

                          > If anyone else has a perspective on what interop means in November 2001,
                          I'm
                          > very interested in hearing more.

                          I see a community where we all test to a set of base tests, and compare
                          results. I can tell you that I have made coding decisions based on these
                          results. The some implementations make heavy use of href's, so the Axis
                          implemention will accept them, but as not all implementations accept these,
                          I have chosen to avoid using href's for simple structs and simple arrays,
                          but in some cases (like arrays of structs) I will make use of them.

                          Some implementations test some extra edge cases. The Ruby (no relation)
                          scripting language folks, for example, have added a fair number of extra
                          tests.

                          - Sam Ruby
                        • Sam Ruby
                          Like WhiteMesa, the Apache implementations have trouble parsing Frontier s response from echoStructArray. Three new data types that have been introduced into
                          Message 12 of 22 , Nov 11, 2001
                            Like WhiteMesa, the Apache implementations have trouble parsing Frontier's
                            response from echoStructArray.

                            Three new data types that have been introduced into the testing since
                            April: HexBinary, Decimal, and Binary. I have colleagues in IBM that tell
                            me that decimal is very important to business and financial types.

                            - Sam Ruby
                          Your message has been successfully submitted and would be delivered to recipients shortly.