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

Re: [soapbuilders] UserLand's interop endpoint up

Expand Messages
  • 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 1 of 22 , Nov 10, 2001
    • 0 Attachment
      > 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.