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

Re: [soapbuilders] UserLand's interop endpoint up

Expand Messages
  • Simon Fell
    FWIW, i wrote a WSDL description for Manila a while back http://www.pocketsoap.com/interop/manila.wsdl Cheers Simon
    Message 1 of 22 , Nov 10, 2001
    • 0 Attachment
      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 2 of 22 , Nov 10, 2001
      • 0 Attachment
        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 3 of 22 , Nov 10, 2001
        • 0 Attachment
          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 4 of 22 , Nov 10, 2001
          • 0 Attachment
            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 5 of 22 , Nov 10, 2001
            • 0 Attachment
              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 6 of 22 , Nov 11, 2001
              • 0 Attachment
                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 7 of 22 , Nov 11, 2001
                • 0 Attachment
                  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.