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

XForms vs. WSDL?

Expand Messages
  • Jørn Wildt
    I was reading Ian Robinsons Using typed links to forms (again, it s a good read) at http://iansrobinson.com/2010/09/02/using-typed-links-to-forms/. Here he
    Message 1 of 23 , Dec 22, 2010
    • 0 Attachment
      I was reading Ian Robinsons "Using typed links to forms" (again, it's a good
      read) at http://iansrobinson.com/2010/09/02/using-typed-links-to-forms/.
      Here he introduces the idea of adding XForms to a link relation, such that
      instead of having only:

      <link rel="" type="" href="" title="">

      and document out of band how to post data to that link, one could have an
      XForm at the end of the link and then use that information as the
      online/inline/in-band documentation. I think that's quite a neat idea, but
      it strikes me that it's getting awfull close to a WSDL spec.

      Both XForm and WSDL defines how to POST data adhering to a specific XML
      schema. If you then add a list of links to XForms, the list would be much
      like the WSDL list of methods/messages. The rel="" types would specify WSDL
      message names.

      In all we could have an HTML 5 list like the one below and call it the WSDL
      method list:

      <dl>
      <dt><a rel="" type="" href="">Title</a></dt>
      <dd>Description</dd>
      </dl>

      Each of the achors then points to an XForm which in turn points to an XML
      schema definition and defines POST urls - just like WSDL does.

      Is this good or bad? Is it better or worse than WSDL and WADL? Other
      opinions?

      Thanks, Jørn
    • mike amundsen
      My reading of Robinson s description does not look very much like WSDL/WADL. - The lightly typed links point to dynamic documents (XForms docs), not static
      Message 2 of 23 , Dec 23, 2010
      • 0 Attachment
        My reading of Robinson's description does not look very much like WSDL/WADL.
        - The "lightly typed links" point to dynamic documents (XForms docs),
        not static schema
        - These XForms can contain as much or as little as the server wishes
        at the moment (including "pre-filled" values)
        - XForms supports more than POST

        The idea I get from Robinson here is that you can use links to forms
        (XForms in his example) as a way to reduce the "inline" application
        control data within any response representation. It seems his notion
        is that this reduces coupling for request operations and helps clean
        up these links by making it a bit less likely to use action-type link
        relation patterns.

        I see WSDL/WADL as doing quite the opposite; increasing coupling
        (clients are expected to "consume" the schema at design-time, not
        run-time) and favoring action-orientation (WSDL is very much an RPC
        pattern).

        mca
        http://amundsen.com/blog/
        http://twitter.com@mamund
        http://mamund.com/foaf.rdf#me


        #RESTFest 2010
        http://rest-fest.googlecode.com




        On Thu, Dec 23, 2010 at 02:28, Jørn Wildt <jw@...> wrote:
        > I was reading Ian Robinsons "Using typed links to forms" (again, it's a good
        > read) at http://iansrobinson.com/2010/09/02/using-typed-links-to-forms/.
        > Here he introduces the idea of adding XForms to a link relation, such that
        > instead of having only:
        >
        >  <link rel="" type="" href="" title="">
        >
        > and document out of band how to post data to that link, one could have an
        > XForm at the end of the link and then use that information as the
        > online/inline/in-band documentation. I think that's quite a neat idea, but
        > it strikes me that it's getting awfull close to a WSDL spec.
        >
        > Both XForm and WSDL defines how to POST data adhering to a specific XML
        > schema. If you then add a list of links to XForms, the list would be much
        > like the WSDL list of methods/messages. The rel="" types would specify WSDL
        > message names.
        >
        > In all we could  have an HTML 5 list like the one below and call it the WSDL
        > method list:
        >
        >  <dl>
        >    <dt><a rel="" type="" href="">Title</a></dt>
        >    <dd>Description</dd>
        >  </dl>
        >
        > Each of the achors then points to an XForm which in turn points to an XML
        > schema definition and defines POST urls - just like WSDL does.
        >
        > Is this good or bad? Is it better or worse than WSDL and WADL? Other
        > opinions?
        >
        > Thanks, Jørn
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
      • William Martinez Pomares
        Hello. I still look for someone that explains in clear terms why is WSDL so bad. At the end the answer is usually it supports RPC, which is not the case
        Message 3 of 23 , Dec 23, 2010
        • 0 Attachment
          Hello.
          I still look for someone that explains in clear terms why is WSDL so bad. At the end the answer is usually it supports RPC, which is not the case lately. Actually, it never was, as document style services should be the ones to use. Oh, well.

          Why is WSDL needed? To describe the actual service consumption process. Where do we find the service? Where do we find the document format we need to send or expect to receive? Where do we find the message send a receive pattern? It is there, in the WSDL.

          Now, REST allows that flow to be discovered, rather than written in one place. Ian's description of the use of XForms achieves that, so they are similar in the goal, may not be so similar in the process. Both will required some out-of-band information. XForms is not forcing the POST method, actually. Is is a way to describe the expected data in a known format, reducing coupling. You may later change the XFORM given some data for the request is changed, and nothing breaks (as a matter of fact, with WSDL should happen the same, but people use compile time binding, stubs, that break that possibility).

          That said, I think the benefit of this form is it avoid, at least a little, the early binding that WADL or WSDL have. So, you are creating totally dynamic clients instead of static ones, pre-build with stubs and things like that. There is still one problem to solve, though, the semantics of the data fields in the Form. But that should be managed as a pre defined context, with a general, agreed upon, glossary.

          Cheers.

          William Martinez Pomares.

          --- In rest-discuss@yahoogroups.com, Jørn Wildt <jw@...> wrote:
          >
          > I was reading Ian Robinsons "Using typed links to forms" (again, it's a good
          > read) at http://iansrobinson.com/2010/09/02/using-typed-links-to-forms/.
          > Here he introduces the idea of adding XForms to a link relation, such that
          > instead of having only:
          >
          > <link rel="" type="" href="" title="">
          >
          > and document out of band how to post data to that link, one could have an
          > XForm at the end of the link and then use that information as the
          > online/inline/in-band documentation. I think that's quite a neat idea, but
          > it strikes me that it's getting awfull close to a WSDL spec.
          >
          > Both XForm and WSDL defines how to POST data adhering to a specific XML
          > schema. If you then add a list of links to XForms, the list would be much
          > like the WSDL list of methods/messages. The rel="" types would specify WSDL
          > message names.
          >
          > In all we could have an HTML 5 list like the one below and call it the WSDL
          > method list:
          >
          > <dl>
          > <dt><a rel="" type="" href="">Title</a></dt>
          > <dd>Description</dd>
          > </dl>
          >
          > Each of the achors then points to an XForm which in turn points to an XML
          > schema definition and defines POST urls - just like WSDL does.
          >
          > Is this good or bad? Is it better or worse than WSDL and WADL? Other
          > opinions?
          >
          > Thanks, Jørn
          >
        • mike amundsen
          William: I did a quick scan an found about 50 discussion threads dating back to mid 2007 on REST-Discuss that at least mentioned WSDL/WADL in some way. WE ve
          Message 4 of 23 , Dec 23, 2010
          • 0 Attachment
            William:

            I did a quick scan an found about 50 discussion threads dating back to
            mid 2007 on REST-Discuss that at least mentioned WSDL/WADL in some
            way. WE've certainly been talking about it quite a bit<g>.

            <snip> I still look for someone that explains in clear terms why is
            WSDL so bad. </snip>
            Personally, I don't find WSDL to be "bad." I do, however, assert that
            the WSDL pattern is not compatible w/ Fielding's particular arch
            model. WSDL, as I've experienced it (and continue to experience it)
            does not employ hypermedia to drive the transfer of application state.
            The WSDL implementations I see today still assume design-time
            consumption and binding of a static, strongly-typed schema. I have yet
            to find WSDL implementations that induce the "Architectural Properties
            of Key Interest"[1] Fielding outlines; especially Modifiability. For
            these reasons, when working in an arch model that follows the
            Fielding's REST, I resist adding WSDL|WADL implementations to the
            architecture.

            <snip>At the end the answer is usually it supports RPC, which is not
            the case lately.</snip>
            I find this interesting. I still see WSDL delivered to me by
            third-party integrators that is in the RPC style. In fact, I cannot
            recall ever implementating a document-style WSDL integration for
            production use. I'd very much like to see some examples of this. The
            closest I've been able to come to any "document-style" w/ WSDL I've
            been given is to implement a single XML message-handler that treats a
            range of calls eash as a unique "message format" instead of a single
            document model for a related set of request/response interactions.
            Maybe I am simply working w/ rather dull folks who are not keeping up
            on WSDL evolution. Please feel free to pass along any pointers you
            have on document-style WSDL implementations (here or off-list, if you
            like).

            [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3

            mca
            http://amundsen.com/blog/
            http://twitter.com@mamund
            http://mamund.com/foaf.rdf#me


            #RESTFest 2010
            http://rest-fest.googlecode.com




            On Thu, Dec 23, 2010 at 09:54, William Martinez Pomares
            <wmartinez@...> wrote:
            >
            > Hello.
            > I still look for someone that explains in clear terms why is WSDL so bad. At the end the answer is usually it supports RPC, which is not the case lately. Actually, it never was, as document style services should be the ones to use. Oh, well.
            >
            > Why is WSDL needed? To describe the actual service consumption process. Where do we find the service? Where do we find the document format we need to send or expect to receive? Where do we find the message send a receive pattern? It is there, in the WSDL.
            >
            > Now, REST allows that flow to be discovered, rather than written in one place. Ian's description of the use of XForms achieves that, so they are similar in the goal, may not be so similar in the process. Both will required some out-of-band information. XForms is not forcing the POST method, actually. Is is a way to describe the expected data in a known format, reducing coupling. You may later change the XFORM given some data for the request is changed, and nothing breaks (as a matter of fact, with WSDL should happen the same, but people use compile time binding, stubs, that break that possibility).
            >
            > That said, I think the benefit of this form is it avoid, at least a little, the early binding that WADL or WSDL have. So, you are creating totally dynamic clients instead of static ones, pre-build with stubs and things like that. There is still one problem to solve, though, the semantics of the data fields in the Form. But that should be managed as a pre defined context, with a general, agreed upon, glossary.
            >
            > Cheers.
            >
            > William Martinez Pomares.
            >
            > --- In rest-discuss@yahoogroups.com, Jørn Wildt <jw@...> wrote:
            >>
            >> I was reading Ian Robinsons "Using typed links to forms" (again, it's a good
            >> read) at http://iansrobinson.com/2010/09/02/using-typed-links-to-forms/.
            >> Here he introduces the idea of adding XForms to a link relation, such that
            >> instead of having only:
            >>
            >>   <link rel="" type="" href="" title="">
            >>
            >> and document out of band how to post data to that link, one could have an
            >> XForm at the end of the link and then use that information as the
            >> online/inline/in-band documentation. I think that's quite a neat idea, but
            >> it strikes me that it's getting awfull close to a WSDL spec.
            >>
            >> Both XForm and WSDL defines how to POST data adhering to a specific XML
            >> schema. If you then add a list of links to XForms, the list would be much
            >> like the WSDL list of methods/messages. The rel="" types would specify WSDL
            >> message names.
            >>
            >> In all we could  have an HTML 5 list like the one below and call it the WSDL
            >> method list:
            >>
            >>   <dl>
            >>     <dt><a rel="" type="" href="">Title</a></dt>
            >>     <dd>Description</dd>
            >>   </dl>
            >>
            >> Each of the achors then points to an XForm which in turn points to an XML
            >> schema definition and defines POST urls - just like WSDL does.
            >>
            >> Is this good or bad? Is it better or worse than WSDL and WADL? Other
            >> opinions?
            >>
            >> Thanks, Jørn
            >>
            >
            >
            >
            >
            > ------------------------------------
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
          • Jørn Wildt
            ... Yes, that s certainly one important difference. With SOAP/WSDL you are given everything up front and have to figure out what to use when. With REST you are
            Message 5 of 23 , Dec 23, 2010
            • 0 Attachment
              > Now, REST allows that flow to be discovered, rather than written in one
              > place

              Yes, that's certainly one important difference. With SOAP/WSDL you are given
              everything up front and have to figure out what to use when. With REST you
              are only served the links that fits the actual state. You cannot do the last
              with WSDL.

              Thanks, for the feedback everybody.

              > That said, I think the benefit of this form is it avoid, at least a
              > little, the early binding that WADL or WSDL have.

              I guess that depends on how you consume the XForm. I would take the
              referenced XML schema in the model definition and automatically create
              classes from it. That would, with my knowledge, help me a lot getting
              started consuming the resource. That would be compile type coupling. It is
              still, from my point of view, easier to work with a native class
              representation of the model then with the bare XML itself.

              But, again, using XForm certainly avoids early binding of the application
              flow.

              /Jørn

              ----- Original Message -----
              From: "William Martinez Pomares" <wmartinez@...>
              To: <rest-discuss@yahoogroups.com>
              Sent: Thursday, December 23, 2010 3:54 PM
              Subject: [rest-discuss] Re: XForms vs. WSDL?



              Hello.
              I still look for someone that explains in clear terms why is WSDL so bad. At
              the end the answer is usually it supports RPC, which is not the case lately.
              Actually, it never was, as document style services should be the ones to
              use. Oh, well.

              Why is WSDL needed? To describe the actual service consumption process.
              Where do we find the service? Where do we find the document format we need
              to send or expect to receive? Where do we find the message send a receive
              pattern? It is there, in the WSDL.

              Now, REST allows that flow to be discovered, rather than written in one
              place. Ian's description of the use of XForms achieves that, so they are
              similar in the goal, may not be so similar in the process. Both will
              required some out-of-band information. XForms is not forcing the POST
              method, actually. Is is a way to describe the expected data in a known
              format, reducing coupling. You may later change the XFORM given some data
              for the request is changed, and nothing breaks (as a matter of fact, with
              WSDL should happen the same, but people use compile time binding, stubs,
              that break that possibility).

              That said, I think the benefit of this form is it avoid, at least a little,
              the early binding that WADL or WSDL have. So, you are creating totally
              dynamic clients instead of static ones, pre-build with stubs and things like
              that. There is still one problem to solve, though, the semantics of the data
              fields in the Form. But that should be managed as a pre defined context,
              with a general, agreed upon, glossary.

              Cheers.

              William Martinez Pomares.

              --- In rest-discuss@yahoogroups.com, Jørn Wildt <jw@...> wrote:
              >
              > I was reading Ian Robinsons "Using typed links to forms" (again, it's a
              > good
              > read) at http://iansrobinson.com/2010/09/02/using-typed-links-to-forms/.
              > Here he introduces the idea of adding XForms to a link relation, such that
              > instead of having only:
              >
              > <link rel="" type="" href="" title="">
              >
              > and document out of band how to post data to that link, one could have an
              > XForm at the end of the link and then use that information as the
              > online/inline/in-band documentation. I think that's quite a neat idea, but
              > it strikes me that it's getting awfull close to a WSDL spec.
              >
              > Both XForm and WSDL defines how to POST data adhering to a specific XML
              > schema. If you then add a list of links to XForms, the list would be much
              > like the WSDL list of methods/messages. The rel="" types would specify
              > WSDL
              > message names.
              >
              > In all we could have an HTML 5 list like the one below and call it the
              > WSDL
              > method list:
              >
              > <dl>
              > <dt><a rel="" type="" href="">Title</a></dt>
              > <dd>Description</dd>
              > </dl>
              >
              > Each of the achors then points to an XForm which in turn points to an XML
              > schema definition and defines POST urls - just like WSDL does.
              >
              > Is this good or bad? Is it better or worse than WSDL and WADL? Other
              > opinions?
              >
              > Thanks, Jørn
              >
            • Jørn Wildt
              ... That is also my experience. /Jørn ... From: mike amundsen To: William Martinez Pomares Cc:
              Message 6 of 23 , Dec 23, 2010
              • 0 Attachment
                > <snip>At the end the answer is usually it supports RPC, which is not
                > the case lately.</snip>
                > I find this interesting. I still see WSDL delivered to me by
                > third-party integrators that is in the RPC style. In fact, I cannot
                > recall ever implementating a document-style WSDL integration for
                > production use.

                That is also my experience.

                /Jørn

                ----- Original Message -----
                From: "mike amundsen" <mamund@...>
                To: "William Martinez Pomares" <wmartinez@...>
                Cc: <rest-discuss@yahoogroups.com>
                Sent: Thursday, December 23, 2010 4:24 PM
                Subject: Re: [rest-discuss] Re: XForms vs. WSDL?


                William:

                I did a quick scan an found about 50 discussion threads dating back to
                mid 2007 on REST-Discuss that at least mentioned WSDL/WADL in some
                way. WE've certainly been talking about it quite a bit<g>.

                <snip> I still look for someone that explains in clear terms why is
                WSDL so bad. </snip>
                Personally, I don't find WSDL to be "bad." I do, however, assert that
                the WSDL pattern is not compatible w/ Fielding's particular arch
                model. WSDL, as I've experienced it (and continue to experience it)
                does not employ hypermedia to drive the transfer of application state.
                The WSDL implementations I see today still assume design-time
                consumption and binding of a static, strongly-typed schema. I have yet
                to find WSDL implementations that induce the "Architectural Properties
                of Key Interest"[1] Fielding outlines; especially Modifiability. For
                these reasons, when working in an arch model that follows the
                Fielding's REST, I resist adding WSDL|WADL implementations to the
                architecture.

                <snip>At the end the answer is usually it supports RPC, which is not
                the case lately.</snip>
                I find this interesting. I still see WSDL delivered to me by
                third-party integrators that is in the RPC style. In fact, I cannot
                recall ever implementating a document-style WSDL integration for
                production use. I'd very much like to see some examples of this. The
                closest I've been able to come to any "document-style" w/ WSDL I've
                been given is to implement a single XML message-handler that treats a
                range of calls eash as a unique "message format" instead of a single
                document model for a related set of request/response interactions.
                Maybe I am simply working w/ rather dull folks who are not keeping up
                on WSDL evolution. Please feel free to pass along any pointers you
                have on document-style WSDL implementations (here or off-list, if you
                like).

                [1]
                http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3

                mca
                http://amundsen.com/blog/
                http://twitter.com@mamund
                http://mamund.com/foaf.rdf#me


                #RESTFest 2010
                http://rest-fest.googlecode.com




                On Thu, Dec 23, 2010 at 09:54, William Martinez Pomares
                <wmartinez@...> wrote:
                >
                > Hello.
                > I still look for someone that explains in clear terms why is WSDL so bad.
                > At the end the answer is usually it supports RPC, which is not the case
                > lately. Actually, it never was, as document style services should be the
                > ones to use. Oh, well.
                >
                > Why is WSDL needed? To describe the actual service consumption process.
                > Where do we find the service? Where do we find the document format we need
                > to send or expect to receive? Where do we find the message send a receive
                > pattern? It is there, in the WSDL.
                >
                > Now, REST allows that flow to be discovered, rather than written in one
                > place. Ian's description of the use of XForms achieves that, so they are
                > similar in the goal, may not be so similar in the process. Both will
                > required some out-of-band information. XForms is not forcing the POST
                > method, actually. Is is a way to describe the expected data in a known
                > format, reducing coupling. You may later change the XFORM given some data
                > for the request is changed, and nothing breaks (as a matter of fact, with
                > WSDL should happen the same, but people use compile time binding, stubs,
                > that break that possibility).
                >
                > That said, I think the benefit of this form is it avoid, at least a
                > little, the early binding that WADL or WSDL have. So, you are creating
                > totally dynamic clients instead of static ones, pre-build with stubs and
                > things like that. There is still one problem to solve, though, the
                > semantics of the data fields in the Form. But that should be managed as a
                > pre defined context, with a general, agreed upon, glossary.
                >
                > Cheers.
                >
                > William Martinez Pomares.
                >
                > --- In rest-discuss@yahoogroups.com, Jørn Wildt <jw@...> wrote:
                >>
                >> I was reading Ian Robinsons "Using typed links to forms" (again, it's a
                >> good
                >> read) at http://iansrobinson.com/2010/09/02/using-typed-links-to-forms/.
                >> Here he introduces the idea of adding XForms to a link relation, such
                >> that
                >> instead of having only:
                >>
                >> <link rel="" type="" href="" title="">
                >>
                >> and document out of band how to post data to that link, one could have an
                >> XForm at the end of the link and then use that information as the
                >> online/inline/in-band documentation. I think that's quite a neat idea,
                >> but
                >> it strikes me that it's getting awfull close to a WSDL spec.
                >>
                >> Both XForm and WSDL defines how to POST data adhering to a specific XML
                >> schema. If you then add a list of links to XForms, the list would be much
                >> like the WSDL list of methods/messages. The rel="" types would specify
                >> WSDL
                >> message names.
                >>
                >> In all we could have an HTML 5 list like the one below and call it the
                >> WSDL
                >> method list:
                >>
                >> <dl>
                >> <dt><a rel="" type="" href="">Title</a></dt>
                >> <dd>Description</dd>
                >> </dl>
                >>
                >> Each of the achors then points to an XForm which in turn points to an XML
                >> schema definition and defines POST urls - just like WSDL does.
                >>
                >> Is this good or bad? Is it better or worse than WSDL and WADL? Other
                >> opinions?
                >>
                >> Thanks, Jørn
                >>
                >
                >
                >
                >
                > ------------------------------------
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
              • William Martinez Pomares
                Hi Mike! Actually, totally agree with you. I want an architectural discussion of why the WSDL definition is wrong and should not be used. In most of the
                Message 7 of 23 , Dec 23, 2010
                • 0 Attachment
                  Hi Mike!
                  Actually, totally agree with you.

                  I want an architectural discussion of why the WSDL definition is wrong and should not be used. In most of the discussions, it is taken for granted that WSDL is simply wrong. In others, as you mention, it is depicted as non RESTful because actual implementations are static binding, build time code generation things. Totally agree, just that WSDL implementation may not be what was intended.

                  See, if we are able to hit a URL looking for data about how to continue my flow, I can have many resources that can help me. One could be an XFORM. The other one can be a WSDL. Both should tell me what to do next. But wait, for that a WSDL should be something I can consume dynamically. There is nothing in the spec that says it should be static. Implementations do not follow that, and thus All implementations of WSDL are unRESTFul. But that is not WSDL's fault, is it?

                  Actually, it may be. You see, prior WSDL 2.0 we had a very static definition of a WS consumption process. Now, WSDL 2.0 provides some patterns or profiles that are not forcing you to use POST, for instance, and may even work for defining HTTP interactions. That is why I say "lately".

                  Still, not much development on WSDL 2.0 has been done, and not much using it in a RESTful way. I posted an example of a REST services described using WSDL 2.0 some time ago, I found in IBM's developers works. Bad news is you can build your client using WSDL as an static description to generate a stub, or create your client to consume the WSDL as any other resource, as part of a larger RESTful web services. Now, guess how many people actually do any of both things? Yep.

                  At the end, it may be a client implementation problem.

                  Here you have you links to similar ideas, using WSDL to define a "RESTFul" implementation. If you look closer, you will see we may end up again with static stubs, but again it is a client problem, isn't it?

                  http://www.ibm.com/developerworks/webservices/library/ws-rest1
                  http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/

                  William Martinez Pomares

                  --- In rest-discuss@yahoogroups.com, mike amundsen <mamund@...> wrote:
                  >
                  > William:
                  >
                  > I did a quick scan an found about 50 discussion threads dating back to
                  > mid 2007 on REST-Discuss that at least mentioned WSDL/WADL in some
                  > way. WE've certainly been talking about it quite a bit<g>.
                  >
                  > <snip> I still look for someone that explains in clear terms why is
                  > WSDL so bad. </snip>
                  > Personally, I don't find WSDL to be "bad." I do, however, assert that
                  > the WSDL pattern is not compatible w/ Fielding's particular arch
                  > model. WSDL, as I've experienced it (and continue to experience it)
                  > does not employ hypermedia to drive the transfer of application state.
                  > The WSDL implementations I see today still assume design-time
                  > consumption and binding of a static, strongly-typed schema. I have yet
                  > to find WSDL implementations that induce the "Architectural Properties
                  > of Key Interest"[1] Fielding outlines; especially Modifiability. For
                  > these reasons, when working in an arch model that follows the
                  > Fielding's REST, I resist adding WSDL|WADL implementations to the
                  > architecture.
                  >
                  > <snip>At the end the answer is usually it supports RPC, which is not
                  > the case lately.</snip>
                  > I find this interesting. I still see WSDL delivered to me by
                  > third-party integrators that is in the RPC style. In fact, I cannot
                  > recall ever implementating a document-style WSDL integration for
                  > production use. I'd very much like to see some examples of this. The
                  > closest I've been able to come to any "document-style" w/ WSDL I've
                  > been given is to implement a single XML message-handler that treats a
                  > range of calls eash as a unique "message format" instead of a single
                  > document model for a related set of request/response interactions.
                  > Maybe I am simply working w/ rather dull folks who are not keeping up
                  > on WSDL evolution. Please feel free to pass along any pointers you
                  > have on document-style WSDL implementations (here or off-list, if you
                  > like).
                  >
                  > [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3
                  >
                  > mca
                  > http://amundsen.com/blog/
                  > http://twitter.com@mamund
                  > http://mamund.com/foaf.rdf#me
                  >
                  >
                  > #RESTFest 2010
                  > http://rest-fest.googlecode.com
                  >
                  >
                  >
                  >
                  > On Thu, Dec 23, 2010 at 09:54, William Martinez Pomares
                  > <wmartinez@...> wrote:
                  > >
                  > > Hello.
                  > > I still look for someone that explains in clear terms why is WSDL so bad. At the end the answer is usually it supports RPC, which is not the case lately. Actually, it never was, as document style services should be the ones to use. Oh, well.
                  > >
                  > > Why is WSDL needed? To describe the actual service consumption process. Where do we find the service? Where do we find the document format we need to send or expect to receive? Where do we find the message send a receive pattern? It is there, in the WSDL.
                  > >
                  > > Now, REST allows that flow to be discovered, rather than written in one place. Ian's description of the use of XForms achieves that, so they are similar in the goal, may not be so similar in the process. Both will required some out-of-band information. XForms is not forcing the POST method, actually. Is is a way to describe the expected data in a known format, reducing coupling. You may later change the XFORM given some data for the request is changed, and nothing breaks (as a matter of fact, with WSDL should happen the same, but people use compile time binding, stubs, that break that possibility).
                  > >
                  > > That said, I think the benefit of this form is it avoid, at least a little, the early binding that WADL or WSDL have. So, you are creating totally dynamic clients instead of static ones, pre-build with stubs and things like that. There is still one problem to solve, though, the semantics of the data fields in the Form. But that should be managed as a pre defined context, with a general, agreed upon, glossary.
                  > >
                  > > Cheers.
                  > >
                  > > William Martinez Pomares.
                  > >
                  > > --- In rest-discuss@yahoogroups.com, Jørn Wildt <jw@> wrote:
                  > >>
                  > >> I was reading Ian Robinsons "Using typed links to forms" (again, it's a good
                  > >> read) at http://iansrobinson.com/2010/09/02/using-typed-links-to-forms/.
                  > >> Here he introduces the idea of adding XForms to a link relation, such that
                  > >> instead of having only:
                  > >>
                  > >>   <link rel="" type="" href="" title="">
                  > >>
                  > >> and document out of band how to post data to that link, one could have an
                  > >> XForm at the end of the link and then use that information as the
                  > >> online/inline/in-band documentation. I think that's quite a neat idea, but
                  > >> it strikes me that it's getting awfull close to a WSDL spec.
                  > >>
                  > >> Both XForm and WSDL defines how to POST data adhering to a specific XML
                  > >> schema. If you then add a list of links to XForms, the list would be much
                  > >> like the WSDL list of methods/messages. The rel="" types would specify WSDL
                  > >> message names.
                  > >>
                  > >> In all we could  have an HTML 5 list like the one below and call it the WSDL
                  > >> method list:
                  > >>
                  > >>   <dl>
                  > >>     <dt><a rel="" type="" href="">Title</a></dt>
                  > >>     <dd>Description</dd>
                  > >>   </dl>
                  > >>
                  > >> Each of the achors then points to an XForm which in turn points to an XML
                  > >> schema definition and defines POST urls - just like WSDL does.
                  > >>
                  > >> Is this good or bad? Is it better or worse than WSDL and WADL? Other
                  > >> opinions?
                  > >>
                  > >> Thanks, Jørn
                  > >>
                  > >
                  > >
                  > >
                  > >
                  > > ------------------------------------
                  > >
                  > > Yahoo! Groups Links
                  > >
                  > >
                  > >
                  > >
                  >
                • William Martinez Pomares
                  Hi again. ... Well, yes, you can. At least with WSDL (let s forget SOAP). WSDL is a web format, registered in IANA, and I can get it dynamically and consume it
                  Message 8 of 23 , Dec 23, 2010
                  • 0 Attachment
                    Hi again.

                    --- In rest-discuss@yahoogroups.com, Jørn Wildt <jw@...> wrote:
                    > Yes, that's certainly one important difference. With SOAP/WSDL you are given
                    > everything up front and have to figure out what to use when. With REST you
                    > are only served the links that fits the actual state. You cannot do the last
                    > with WSDL.

                    Well, yes, you can. At least with WSDL (let's forget SOAP). WSDL is a web format, registered in IANA, and I can get it dynamically and consume it dynamically. Nobody does it because of tools, granted. The shame is on the tool designers.

                    > I guess that depends on how you consume the XForm.

                    Totally true. Knowing the XFORM up front will make you write a rigid client. Same for WSDL. Consuming the XFORM dynamically will make everybody happy. It is harder with WSDL, but possible too.
                    Here the real difference is then the actual implementation, plus, I would say, XFORM is still light, and WSDL we may label it as "heavy".

                    Cheers!

                    William Martinez Pomares.
                  • mike amundsen
                    William: I want an architectural discussion of why the WSDL definition is wrong and should not be used. In most of the discussions, it is taken for
                    Message 9 of 23 , Dec 23, 2010
                    • 0 Attachment
                      William:

                      <snip>
                      I want an architectural discussion of why the WSDL definition is wrong
                      and should not be used. In most of the discussions, it is taken for
                      granted that WSDL is simply wrong. In others, as you mention, it is
                      depicted as non RESTful because actual implementations are static
                      binding, build time code generation things. Totally agree, just that
                      WSDL implementation may not be what was intended.
                      </snip>
                      Well, any arch discussion will have a context. In the context of the
                      REST arch model, I find the WSDL pattern (WSDL, WADL, GData Python
                      API, etc.) to be inappropriate. I've already mentioned a handful of
                      reasons. Possibly one I did not emphasize is the lack of hypermedia in
                      this external definition pattern. While WSDL can do a good job of
                      expressing the request and response details, I've yet to see WSDL do a
                      good job expressing the state transition details. IOW, which steps are
                      first, second, third, etc. These "steps", in my experience almost
                      always depend on the state of things at the moment and are not at all
                      easy to properly express in a static document.

                      I find it much easier to express the valid state transitions in the
                      context of the _current_ state transition. Thus, when working in a
                      REST arch implementation, I continue to favor including app control
                      information in the response representation rather than in an external
                      document. I've been toying with pulling more and more details on these
                      transitions out of client code and into the message. I've even been
                      experimenting with putting some of the state transition detail in
                      _external_ documents, but have yet to find the WSDL pattern helpful
                      for that work.

                      <snip>
                      See, if we are able to hit a URL looking for data about how to
                      continue my flow, I can have many resources that can help me. One
                      could be an XFORM. The other one can be a WSDL. Both should tell me
                      what to do next. But wait, for that a WSDL should be something I can
                      consume dynamically. There is nothing in the spec that says it should
                      be static. Implementations do not follow that, and thus All
                      implementations of WSDL are unRESTFul. But that is not WSDL's fault,
                      is it?
                      </snip>
                      While I can see that it would be _possible_ to use WSDL at runtime,
                      I've yet to see a viable example. I've toyed with this a bit and found
                      it a non-starter. I'm open to seeing working examples of this. I'm not
                      really interested in reading more technical papers about it, tho. I've
                      read them for years and still see no tangible work in this area.

                      <snip>
                      Here you have you links to similar ideas, using WSDL to define a
                      "RESTFul" implementation. If you look closer, you will see we may end
                      up again with static stubs, but again it is a client problem, isn't
                      it?

                      http://www.ibm.com/developerworks/webservices/library/ws-rest1
                      http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/
                      </snip>
                      I read this material years ago. Nothing there leads me to believe WSDL
                      is appropriate for REST style arch models. From my POV, WSDL 2.0 is
                      overly verbose (w/o the corresponding value in the added material) and
                      lacking in key information needed at runtime including valid "next
                      steps" in state transitions. I find this last item vital when working
                      in any M2M scenario.

                      Now, oo get back to your initial sentence, let's have an architecture
                      discussion about WSDL. To wit:
                      "Under what arch model is WSDL a valid|viable component to the implementation?"

                      IOW, drop the idea of arguing the merits of WSDL + REST for a moment.
                      Instead, how about describing an arch model (any arch model) where
                      WSDL (and it's relations) has little or no friction with the desired
                      system properties and the constraints you use to induce those
                      properties.

                      What does _that_ arch model look like?

                      mca
                      http://amundsen.com/blog/
                      http://twitter.com@mamund
                      http://mamund.com/foaf.rdf#me


                      #RESTFest 2010
                      http://rest-fest.googlecode.com




                      On Thu, Dec 23, 2010 at 13:54, William Martinez Pomares
                      <wmartinez@...> wrote:
                      > Hi Mike!
                      > Actually, totally agree with you.
                      >
                      > I want an architectural discussion of why the WSDL definition is wrong and should not be used. In most of the discussions, it is taken for granted that WSDL is simply wrong. In others, as you mention, it is depicted as non RESTful because actual implementations are static binding, build time code generation things. Totally agree, just that WSDL implementation may not be what was intended.
                      >
                      > See, if we are able to hit a URL looking for data about how to continue my flow, I can have many resources that can help me. One could be an XFORM. The other one can be a WSDL. Both should tell me what to do next. But wait, for that a WSDL should be something I can consume dynamically. There is nothing in the spec that says it should be static. Implementations do not follow that, and thus All implementations of WSDL are unRESTFul. But that is not WSDL's fault, is it?
                      >
                      > Actually, it may be. You see, prior WSDL 2.0 we had a very static definition of a WS consumption process. Now, WSDL 2.0 provides some patterns or profiles that are not forcing you to use POST, for instance, and may even work for defining HTTP interactions. That is why I say "lately".
                      >
                      > Still, not much development on WSDL 2.0 has been done, and not much using it in a RESTful way. I posted an example of a REST services described using WSDL 2.0 some time ago, I found in IBM's developers works. Bad news is you can build your client using WSDL as an static description to generate a stub, or create your client to consume the WSDL as any other resource, as part of a larger RESTful web services. Now, guess how many people actually do any of both things? Yep.
                      >
                      > At the end, it may be a client implementation problem.
                      >
                      > Here you have you links to similar ideas, using WSDL to define a "RESTFul" implementation. If you look closer, you will see we may end up again with static stubs, but again it is a client problem, isn't it?
                      >
                      > http://www.ibm.com/developerworks/webservices/library/ws-rest1
                      > http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/
                      >
                      > William Martinez Pomares
                      >
                      > --- In rest-discuss@yahoogroups.com, mike amundsen <mamund@...> wrote:
                      >>
                      >> William:
                      >>
                      >> I did a quick scan an found about 50 discussion threads dating back to
                      >> mid 2007 on REST-Discuss that at least mentioned WSDL/WADL in some
                      >> way. WE've certainly been talking about it quite a bit<g>.
                      >>
                      >> <snip> I still look for someone that explains in clear terms why is
                      >> WSDL so bad. </snip>
                      >> Personally, I don't find WSDL to be "bad." I do, however, assert that
                      >> the WSDL pattern is not compatible w/ Fielding's particular arch
                      >> model. WSDL, as I've experienced it (and continue to experience it)
                      >> does not employ hypermedia to drive the transfer of application state.
                      >> The WSDL implementations I see today still assume design-time
                      >> consumption and binding of a static, strongly-typed schema. I have yet
                      >> to find WSDL implementations that induce the "Architectural Properties
                      >> of Key Interest"[1] Fielding outlines; especially Modifiability. For
                      >> these reasons, when working in an arch model that follows the
                      >> Fielding's REST, I resist adding  WSDL|WADL implementations to the
                      >> architecture.
                      >>
                      >> <snip>At the end the answer is usually it supports RPC, which is not
                      >> the case lately.</snip>
                      >> I find this interesting. I still see WSDL delivered to me by
                      >> third-party integrators that is in the RPC style. In fact, I cannot
                      >> recall ever implementating a document-style WSDL integration for
                      >> production use. I'd very much like to see some examples of this. The
                      >> closest I've been able to come to any "document-style" w/ WSDL I've
                      >> been given is to implement a single XML message-handler that treats a
                      >> range of calls eash as a unique "message format" instead of a single
                      >> document model for a related set of request/response interactions.
                      >> Maybe I am simply working w/ rather dull folks who are not keeping up
                      >> on WSDL evolution. Please feel free to pass along any pointers you
                      >> have on document-style WSDL implementations (here or off-list, if you
                      >> like).
                      >>
                      >> [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/net_app_arch.htm#sec_2_3
                      >>
                      >> mca
                      >> http://amundsen.com/blog/
                      >> http://twitter.com@mamund
                      >> http://mamund.com/foaf.rdf#me
                      >>
                      >>
                      >> #RESTFest 2010
                      >> http://rest-fest.googlecode.com
                      >>
                      >>
                      >>
                      >>
                      >> On Thu, Dec 23, 2010 at 09:54, William Martinez Pomares
                      >> <wmartinez@...> wrote:
                      >> >
                      >> > Hello.
                      >> > I still look for someone that explains in clear terms why is WSDL so bad. At the end the answer is usually it supports RPC, which is not the case lately. Actually, it never was, as document style services should be the ones to use. Oh, well.
                      >> >
                      >> > Why is WSDL needed? To describe the actual service consumption process. Where do we find the service? Where do we find the document format we need to send or expect to receive? Where do we find the message send a receive pattern? It is there, in the WSDL.
                      >> >
                      >> > Now, REST allows that flow to be discovered, rather than written in one place. Ian's description of the use of XForms achieves that, so they are similar in the goal, may not be so similar in the process. Both will required some out-of-band information. XForms is not forcing the POST method, actually. Is is a way to describe the expected data in a known format, reducing coupling. You may later change the XFORM given some data for the request is changed, and nothing breaks (as a matter of fact, with WSDL should happen the same, but people use compile time binding, stubs, that break that possibility).
                      >> >
                      >> > That said, I think the benefit of this form is it avoid, at least a little, the early binding that WADL or WSDL have. So, you are creating totally dynamic clients instead of static ones, pre-build with stubs and things like that. There is still one problem to solve, though, the semantics of the data fields in the Form. But that should be managed as a pre defined context, with a general, agreed upon, glossary.
                      >> >
                      >> > Cheers.
                      >> >
                      >> > William Martinez Pomares.
                      >> >
                      >> > --- In rest-discuss@yahoogroups.com, Jørn Wildt <jw@> wrote:
                      >> >>
                      >> >> I was reading Ian Robinsons "Using typed links to forms" (again, it's a good
                      >> >> read) at http://iansrobinson.com/2010/09/02/using-typed-links-to-forms/.
                      >> >> Here he introduces the idea of adding XForms to a link relation, such that
                      >> >> instead of having only:
                      >> >>
                      >> >>   <link rel="" type="" href="" title="">
                      >> >>
                      >> >> and document out of band how to post data to that link, one could have an
                      >> >> XForm at the end of the link and then use that information as the
                      >> >> online/inline/in-band documentation. I think that's quite a neat idea, but
                      >> >> it strikes me that it's getting awfull close to a WSDL spec.
                      >> >>
                      >> >> Both XForm and WSDL defines how to POST data adhering to a specific XML
                      >> >> schema. If you then add a list of links to XForms, the list would be much
                      >> >> like the WSDL list of methods/messages. The rel="" types would specify WSDL
                      >> >> message names.
                      >> >>
                      >> >> In all we could  have an HTML 5 list like the one below and call it the WSDL
                      >> >> method list:
                      >> >>
                      >> >>   <dl>
                      >> >>     <dt><a rel="" type="" href="">Title</a></dt>
                      >> >>     <dd>Description</dd>
                      >> >>   </dl>
                      >> >>
                      >> >> Each of the achors then points to an XForm which in turn points to an XML
                      >> >> schema definition and defines POST urls - just like WSDL does.
                      >> >>
                      >> >> Is this good or bad? Is it better or worse than WSDL and WADL? Other
                      >> >> opinions?
                      >> >>
                      >> >> Thanks, Jørn
                      >> >>
                      >> >
                      >> >
                      >> >
                      >> >
                      >> > ------------------------------------
                      >> >
                      >> > Yahoo! Groups Links
                      >> >
                      >> >
                      >> >
                      >> >
                      >>
                      >
                      >
                      >
                      >
                      > ------------------------------------
                      >
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >
                    • William Martinez Pomares
                      Mike. Ok, this is interesting, we can get several valid points in the discussion. But first, let me clarify I m not in favor of WSDL as a hard believer it will
                      Message 10 of 23 , Dec 23, 2010
                      • 0 Attachment
                        Mike.
                        Ok, this is interesting, we can get several valid points in the discussion. But first, let me clarify I'm not in favor of WSDL as a hard believer it will make the world happier, or that it is the only way to work on REST. It is just that, without a context, running away from it with no reason is such non-sense that makes me wonder, and I end up like a defender of the lost cause.

                        Now. Let's see:

                        <snip>
                        Well, any arch discussion will have a context. In the context of the REST arch model, I find the WSDL pattern (WSDL, WADL, GData Python API, etc.) to be inappropriate. I've already mentioned a handful of reasons. Possibly one I did not emphasize is the lack of hypermedia in this external definition pattern.
                        </snip>

                        That's an interesting POV. I would not to see WSDL as a pattern, linked to external additional things. Just think of it as a document format for a moment.

                        <snip>
                        While WSDL can do a good job of expressing the request and response details, I've yet to see WSDL do a good job expressing the state transition details. IOW, which steps are first, second, third, etc. These "steps", in my experience almost always depend on the state of things at the moment and are not at all easy to properly express in a static document.
                        </snip>

                        Totally agree with you. I would not recommend either trying to define the complete state machine in one doc, unless you have particular need to have instances of a state machine that may run longer and in parallel with other instances (versioning). And that is beyond REST.

                        For REST, all the transitions may be based on the actual state. I would not use WSDL for a one place description of those transitions, and it is not made for that. It is made for defining the document formats, bindings and message delivery patterns.

                        I guess what gets confused here with REST transitions is the message pattern idea. Those patterns may go beyond the REST style, as they were not designed for that. Actually, the messages are one way, delivery, while a REST interaction in HTTP implementation requires a request and a response.

                        And you are right, the articles I posted are just an example of how WSDL is thought to be compatible with REST, but following that philosophy of enclosing all the interactions. That, let's say, is a pattern (or antipattern, so to speak).

                        <snip>
                        I've been toying with pulling more and more details on these transitions out of client code and into the message. I've even been experimenting with putting some of the state transition detail in _external_ documents, but have yet to find the WSDL pattern helpful for that work.
                        </snip>
                        Yes, actually I cheer the state transition info IN the message. Not in the code nor in external docs. If the WSDL is part of it, then the WSDL should be THE message, not an external doc.

                        Last point on WSDL and REST: WSDL is not the whole, but a document you may get in one get operation, that should tell you the format of the document you need to send next, the URI, and any expected response, if any, once you get the response, that one should drive you to the next one and so on. Just like an XFORM, but yes, awfully verbose.

                        Now, about what architectural style may WSDL be suitable? Well some SOA of course. WSDL was meant to be a web services implementation definition, describing the messages in XML format, the message exchange pattern and the underlying protocol binding. If you have a system not totally built on top of HTTP, with complex exchange patterns and a mix of data and processing intensive operations, then WSDL may (MAY) help you with little bits of automation for client construction. WSDL was not built for REST, and surely REST was not defined for the system I describe, although one or two of the nodes are on the web. Still, WSDL is not magical and may not fit all implementations, may work for integrated application, not necessarily for distributed ones.

                        But describing about the essential SOA constrains and properties may take longer in this comment.

                        And, I hope you now know that I'm not totally comfortable with the idea of REST being the natural SOA solution. It isn't, and maybe that is a discussion we need to start in another thread.

                        Cheers!

                        William Martinez Pomares.

                        BTW even Wooden seems abandoned, so that is why you see almost no practical work on this. Frank Cohen, when I told him WSDL 2.0 was official, smiled back and said: "Who cares?". Oh, well.
                      • mike amundsen
                        William: Thanks for the thoughtful post. It will take me some time to take it all in and, since I think our talk is straying from REST, I ll respond at length
                        Message 11 of 23 , Dec 23, 2010
                        • 0 Attachment
                          William:

                          Thanks for the thoughtful post. It will take me some time to take it
                          all in and, since I think our talk is straying from REST, I'll respond
                          at length directly to you (off list).

                          As always,it is great to converse w/ you on topics like this.

                          Thanks.

                          mca
                          http://amundsen.com/blog/
                          http://twitter.com@mamund
                          http://mamund.com/foaf.rdf#me


                          #RESTFest 2010
                          http://rest-fest.googlecode.com




                          On Thu, Dec 23, 2010 at 17:25, William Martinez Pomares
                          <wmartinez@...> wrote:
                          > Mike.
                          > Ok, this is interesting, we can get several valid points in the discussion. But first, let me clarify I'm not in favor of WSDL as a hard believer it will make the world happier, or that it is the only way to work on REST. It is just that, without a context, running away from it with no reason is such non-sense that makes me wonder, and I end up like a defender of the lost cause.
                          >
                          > Now. Let's see:
                          >
                          > <snip>
                          >  Well, any arch discussion will have a context. In the context of the REST arch model, I find the WSDL pattern (WSDL, WADL, GData Python API, etc.) to be inappropriate. I've already mentioned a handful of reasons. Possibly one I did not emphasize is the lack of hypermedia in this external definition pattern.
                          > </snip>
                          >
                          > That's an interesting POV. I would not to see WSDL as a pattern, linked to external additional things. Just think of it as a document format for a moment.
                          >
                          > <snip>
                          > While WSDL can do a good job of expressing the request and response details, I've yet to see WSDL do a good job expressing the state transition details. IOW, which steps are first, second, third, etc. These "steps", in my experience almost always depend on the state of things at the moment and are not at all easy to properly express in a static document.
                          > </snip>
                          >
                          > Totally agree with you. I would not recommend either trying to define the complete state machine in one doc, unless you have particular need to have instances of a state machine that may run longer and in parallel with other instances (versioning). And that is beyond REST.
                          >
                          > For REST, all the transitions may be based on the actual state. I would not use WSDL for a one place description of those transitions, and it is not made for that. It is made for defining the document formats, bindings and message delivery patterns.
                          >
                          > I guess what gets confused here with REST transitions is the message pattern idea. Those patterns may go beyond the REST style, as they were not designed for that. Actually, the messages are one way, delivery, while a REST interaction in HTTP implementation requires a request and a response.
                          >
                          > And you are right, the articles I posted are just an example of how WSDL is thought to be compatible with REST, but following that philosophy of enclosing all the interactions. That, let's say, is a pattern (or antipattern, so to speak).
                          >
                          > <snip>
                          > I've been toying with pulling more and more details on these transitions out of client code and into the message. I've even been experimenting with putting some of the state transition detail in _external_ documents, but have yet to find the WSDL pattern helpful for that work.
                          > </snip>
                          > Yes, actually I cheer the state transition info IN the message. Not in the code nor in external docs. If the WSDL is part of it, then the WSDL should be THE message, not an external doc.
                          >
                          > Last point on WSDL and REST: WSDL is not the whole, but a document you may get in one get operation, that should tell you the format of the document you need to send next, the URI, and any expected response, if any, once you get the response, that one should drive you to the next one and so on. Just like an XFORM, but yes, awfully verbose.
                          >
                          > Now, about what architectural style may WSDL be suitable? Well some SOA of course. WSDL was meant to be a web services implementation definition, describing the messages in XML format, the message exchange pattern and the underlying protocol binding. If you have a system not totally built on top of HTTP, with complex exchange patterns and a mix of data and processing intensive operations, then WSDL may (MAY) help you with little bits of automation for client construction. WSDL was not built for REST, and surely REST was not defined for the system I describe, although one or two of the nodes are on the web. Still, WSDL is not magical and may not fit all implementations, may work for integrated application, not necessarily for distributed ones.
                          >
                          > But describing about the essential SOA constrains and properties may take longer in this comment.
                          >
                          > And, I hope you now know that I'm not totally comfortable with the idea of REST being the natural SOA solution. It isn't, and maybe that is a discussion we need to start in another thread.
                          >
                          > Cheers!
                          >
                          > William Martinez Pomares.
                          >
                          > BTW even Wooden seems abandoned, so that is why you see almost no practical work on this. Frank Cohen, when I told him WSDL 2.0 was official, smiled back and said: "Who cares?".  Oh, well.
                          >
                          >
                          >
                          >
                          > ------------------------------------
                          >
                          > Yahoo! Groups Links
                          >
                          >
                          >
                          >
                        • Eric J. Bowman
                          ... I disagree with the premise. REST s uniform interface requires generic media and data types. The example creates an application-specific media and data
                          Message 12 of 23 , Dec 23, 2010
                          • 0 Attachment
                            Jørn Wildt wrote:
                            >
                            > I was reading Ian Robinsons "Using typed links to forms" (again, it's
                            > a good read)
                            >

                            I disagree with the premise. REST's uniform interface requires generic
                            media and data types. The example creates an application-specific media
                            and data type (ordering one brand of coffee), where even domain-specific
                            media and data types (ordering coffee) would be too fine-grained, where
                            network-specific (generic to IP) media and data types are called for
                            (ordering anything).

                            Why not just use XForms forwards instead of backwards, using
                            standardized data types and link relations like the thesis says? I
                            don't understand how this would be less pragmatic than the example
                            given, particularly to the extent of using pragmatism to justify
                            deliberately avoiding the hypertext constraint in favor of increased
                            coupling.

                            Link relations aren't coupling when they're standardized, i.e. common
                            knowledge at the IP layer across numerous protocols and data types. The
                            difference is the key difference in REST -- the uniform interface is
                            network-based, extended link relations are library-based (which is fine
                            for domain-specific vocabulary, not for directing application flow by
                            baking HTTP methods into them and such). Methods, headers, data types
                            and link relations nobody's ever heard of before you minted them are
                            *not* the same thing as the standardized uniform interface Roy's thesis
                            describes.

                            >
                            > and document out of band how to post data to that link
                            >

                            Doesn't compute. The whole point of the hypertext constraint is that
                            hypertext controls are used to document this in-band, relying on the
                            common-knowledge processing model of ubiquitous media types. Maybe
                            this other proposed architectural style has merit, I'm not judging,
                            only stating that it can't be REST if there's no hypertext constraint.

                            >
                            > have an XForm at the end of the link and then use that information as
                            > the online/inline/in-band documentation. I think that's quite a neat
                            > idea, but it strikes me that it's getting awfull close to a WSDL spec.
                            >

                            Exactly. IDLs, and hypertext-driven APIs, aren't the same paradigm.
                            It hadn't occurred to me that XForms could be repurposed as an IDL, but
                            my advice is, don't. IDL-driven APIs are NOT REST.

                            >
                            > Both XForm and WSDL defines how to POST data adhering to a specific
                            > XML schema.
                            >

                            Not exactly. IDLs are not self-documenting hypertext controls -- they
                            cannot instruct a user-agent as to the default values, validate input
                            (type=e-mail is one thing, black/whitelists are another) using code-on-
                            demand; nor do they provide any mechanism to link to documentation (or
                            render it outright as a pop-up) to inform the decision-making of the
                            humans or machines (RDFa doesn't make much sense in an IDL) interacting
                            with the API.

                            >
                            > If you then add a list of links to XForms, the list would be much
                            > like the WSDL list of methods/messages.
                            >

                            You say that like it's a good thing? ;-) There are two approaches to
                            the problem of distributing the object interface instead of distributing
                            the object. One is to distribute a definition of your custom interface.
                            The other is to use the distributed uniform interface, which is generic
                            -- if all objects use the same interface, what's left to describe in
                            an IDL?

                            >
                            > The rel="" types would specify WSDL message names.
                            >

                            In HTTP, REST's uniform interface includes, amongst other methods: GET,
                            PUT, POST, PATCH and DELETE. If your interfaces are object-specific
                            (hint, hint) then yeah, IDLs make sense, but I don't know how you start
                            from tunneling custom methods (expressed as link relations) over POST
                            and arrive at REST.

                            >
                            > In all we could have an HTML 5 list like the one below and call it
                            > the WSDL method list:
                            >
                            > <dl>
                            > <dt><a rel="" type="" href="">Title</a></dt>
                            > <dd>Description</dd>
                            > </dl>
                            >
                            > Each of the achors then points to an XForm which in turn points to an
                            > XML schema definition and defines POST urls - just like WSDL does.
                            >
                            > Is this good or bad? Is it better or worse than WSDL and WADL? Other
                            > opinions?
                            >

                            I really have no basis for comparing non-RESTful approaches. REST is a
                            hypertext-driven architectural style based on standardized media types
                            and standardized link relations. While extended link relations may be
                            used to inform m2m decision-making, if the semantics of the interaction
                            between connectors is that you can GET something and PUT it back then
                            just use rel='edit' instead of defining an unlimited number of link
                            relations to describe resource type (a server-side concern) to the
                            client in lieu of using standardized hypertext controls.

                            Note that rel='edit' says nothing about HTTP methods, or even HTTP,
                            though. If you're assuming it means PUT, I have no idea how you'd
                            reach that conclusion, even if the media type were application/atom+xml,
                            because only a hypertext control communicates method to me. There's
                            nothing in the communication between connectors which says "RFC 5023 in
                            use". Only hypertext controls provide such instructions, which may be
                            to GET the rel='edit'...

                            Or, I may PATCH that resource -- but this is communicated through the
                            hypertext representation, including the Allow and Accept(-*) headers.
                            One hypertext control indicates that the entire "instance" (to stick
                            with XForms) may be PUT as application/atom+xml, while another hypertext
                            control indicates that categories may be PATCHed using an instance of
                            application/atomcat+xml -- but this has no bearing on the link relation!

                            I have no clue how any IDL- or schema-based approach supports the above
                            paragraph, except as part of an API being driven by out-of-band
                            information. When folks start talking about RESTful IDLs, schemae and
                            overloaded link relations, my reaction is WTF are you people even
                            *talking* about, as I've mentioned before. My snappy comeback, is why
                            not just use rel='{HTTP method}' and have done with it? Things that
                            are not hypertext controls:

                            IDLs (even with a registered media type)
                            media type definitions (registration doesn't indicate suitability)
                            schemas (even with a registered media type)
                            link relations (even when standardized)

                            These things have their place, and I've even mentioned how IDLs could
                            be used as a response to OPTIONS requests, but they are *not*
                            substitutes for the hypertext constraint. Inferring things out-of-band
                            bad, self-documenting hypertext APIs good.

                            -Eric
                          • Eric J. Bowman
                            ... Nothing wrong with defending lost causes... :-) But, I fail to see how any IDL-based approach can describe my vapor-example (I ll get around to the live
                            Message 13 of 23 , Dec 23, 2010
                            • 0 Attachment
                              "William Martinez Pomares" wrote:
                              >
                              > It is just that, without a context, running away from it with no
                              > reason is such non-sense that makes me wonder, and I end up like a
                              > defender of the lost cause.
                              >

                              Nothing wrong with defending lost causes... :-) But, I fail to see
                              how any IDL-based approach can describe my vapor-example (I'll get
                              around to the live XForms example on my demo someday) with sufficient
                              detail to instruct (h or m) users as to the *goals* behind using PUT
                              application/atom+xml vs. PATCH application/atomcat+xml. With IDLs, the
                              categories allowed in the PATCH would be listed in a schema, and that
                              schema would need to be updated when the list of categories changes.

                              Why not just give the current list in-band as part of a hypertext
                              control? IDLs add whole layers of indirection which simply aren't
                              needed when hypertext controls are used instead. REST is about
                              declaring to generic user-agents what state transitions are possible,
                              not what application-specific user-agents may infer from out-of-band
                              understanding of the application flow.

                              IOW, I'm turning your question back on you -- I've never seen an IDL
                              that can describe the hypertext-driven APIs I write. That's my
                              context, but I try to keep an open mind, so all anyone has to do to
                              convince me that I'm being nonsensical or dogmatic in my opposition to
                              IDLs is show me what I'm missing by giving a counter-example of what an
                              API would look like which allows an Atom Entry to be PUT-edited or
                              PATCH-tagged without relying on out-of-band inferences (i.e. rel='edit'
                              means PUT, and rel='some URI' means PATCH) specific to the application
                              or the domain (as opposed to generic).

                              -Eric
                            • Eric J. Bowman
                              ... I understand; please don t take my hard-ass response personally (always good advice for everyone). For further reading, please see:
                              Message 14 of 23 , Dec 23, 2010
                              • 0 Attachment
                                "William Martinez Pomares" wrote:
                                >
                                > But first, let me clarify I'm not in favor of WSDL as a hard believer
                                > it will make the world happier, or that it is the only way to work on
                                > REST.
                                >

                                I understand; please don't take my hard-ass response personally (always
                                good advice for everyone). For further reading, please see:

                                http://bitworking.org/news/193/Do-we-need-WADL

                                Or, in lieu of revisiting REST-vs-SOAP, peruse Mark Baker's weblog
                                archives, or these:

                                http://www.25hoursaday.com/weblog/2008/08/17/ExplainingRESTToDamienKatz.aspx
                                http://www.infoq.com/articles/mark-baker-REST
                                http://www.kintespace.com/rasx37.html
                                http://www.prescod.net/rest/rest_vs_soap_overview/

                                -Eric
                              • Eric J. Bowman
                                ... Yes, I m aware of @default. However, in the real world, manipulating one control may change the default of another. XForms allows this to be declarative,
                                Message 15 of 23 , Dec 23, 2010
                                • 0 Attachment
                                  >
                                  > >
                                  > > Both XForm and WSDL defines how to POST data adhering to a specific
                                  > > XML schema.
                                  > >
                                  >
                                  > Not exactly. IDLs are not self-documenting hypertext controls -- they
                                  > cannot instruct a user-agent as to the default values...
                                  >

                                  Yes, I'm aware of @default. However, in the real world, manipulating
                                  one control may change the default of another. XForms allows this to
                                  be declarative, HTML forms plus javascript allows it to be imperative;
                                  whereas IDLs provide no such facility in-band (such relationships must
                                  be inferred from a schema, coupling consumer to producer, precluding
                                  generic consumers (unless and until I see an example of one)).

                                  -Eric
                                • Eric J. Bowman
                                  ... +1 The problem with treating rel= edit (*) as a hypertext control, is that it provides no facility for doing client-side input validation according to a
                                  Message 16 of 23 , Dec 23, 2010
                                  • 0 Attachment
                                    mike amundsen wrote:
                                    >
                                    > I find it much easier to express the valid state transitions in the
                                    > context of the _current_ state transition. Thus, when working in a
                                    > REST arch implementation, I continue to favor including app control
                                    > information in the response representation rather than in an external
                                    > document. I've been toying with pulling more and more details on these
                                    > transitions out of client code and into the message...
                                    >

                                    +1

                                    The problem with treating rel='edit' (*) as a hypertext control, is that
                                    it provides no facility for doing client-side input validation according
                                    to a schema (unless that schema, or a link to it, is baked into the
                                    user-agent); whereas XForms can provide a schema-driven input control,
                                    and even declare the method to be POST instead of PUT or change this
                                    (or the media type of the PUT or POST request) on-the-fly (as opposed
                                    to baking rel='edit'=PUT and the media type into the user-agent, which
                                    requires generic clients to somehow infer this information to use the
                                    API).

                                    * or any other link relation, standardized or not -- rel='next' isn't a
                                    hypertext control, the <link> or <a> it appears in is the hypertext
                                    control

                                    -Eric
                                  • William Martinez Pomares
                                    Well, Eric, please recall this is not a defense of WSDL, just an academic, rich discussion :D The without a context refers to dooming the IDLs just because
                                    Message 17 of 23 , Dec 23, 2010
                                    • 0 Attachment
                                      Well, Eric, please recall this is not a defense of WSDL, just an academic, rich discussion :D

                                      The "without a context" refers to dooming the IDLs just because they are IDLs, in any possible situation. That said, I totally agree with what you say, taken for granted the WSDL is an IDL used as an out-of-band definition of flow for REST.

                                      As Mike pointed out, removing REST from the picture, and trying to make WSDL a dynamically consumable, lean document, not oriented to hypertext driven APIs but to messaging ones, not necessarily over HTTP: is still WSDL as bad? Maybe it is good for something, in other context.

                                      So, to answer your question, I guess no, it makes no sense to use a IDL to represent REST Hypertext states transitions or flows. I can almost call it an oxymoron. I hate RPC for services implementation, still RPC may be good in some other situations. Just not for REST anyway.

                                      Cheers!

                                      William Martinez Pomares.

                                      --- In rest-discuss@yahoogroups.com, "Eric J. Bowman" <eric@...> wrote:
                                      >
                                      > "William Martinez Pomares" wrote:
                                      > >
                                      > > It is just that, without a context, running away from it with no
                                      > > reason is such non-sense that makes me wonder, and I end up like a
                                      > > defender of the lost cause.
                                      > >
                                      >
                                      > Nothing wrong with defending lost causes... :-) But, I fail to see
                                      > how any IDL-based approach can describe my vapor-example (I'll get
                                      > around to the live XForms example on my demo someday) with sufficient
                                      > detail to instruct (h or m) users as to the *goals* behind using PUT
                                      > application/atom+xml vs. PATCH application/atomcat+xml. With IDLs, the
                                      > categories allowed in the PATCH would be listed in a schema, and that
                                      > schema would need to be updated when the list of categories changes.
                                      >
                                      > Why not just give the current list in-band as part of a hypertext
                                      > control? IDLs add whole layers of indirection which simply aren't
                                      > needed when hypertext controls are used instead. REST is about
                                      > declaring to generic user-agents what state transitions are possible,
                                      > not what application-specific user-agents may infer from out-of-band
                                      > understanding of the application flow.
                                      >
                                      > IOW, I'm turning your question back on you -- I've never seen an IDL
                                      > that can describe the hypertext-driven APIs I write. That's my
                                      > context, but I try to keep an open mind, so all anyone has to do to
                                      > convince me that I'm being nonsensical or dogmatic in my opposition to
                                      > IDLs is show me what I'm missing by giving a counter-example of what an
                                      > API would look like which allows an Atom Entry to be PUT-edited or
                                      > PATCH-tagged without relying on out-of-band inferences (i.e. rel='edit'
                                      > means PUT, and rel='some URI' means PATCH) specific to the application
                                      > or the domain (as opposed to generic).
                                      >
                                      > -Eric
                                      >
                                    • Eric J. Bowman
                                      ... Yup. One which I hope, over time, motivates as much effort going into creating new-n-improved hypertext-control markup languages as currently goes into
                                      Message 18 of 23 , Dec 23, 2010
                                      • 0 Attachment
                                        "William Martinez Pomares" wrote:
                                        >
                                        > Well, Eric, please recall this is not a defense of WSDL, just an
                                        > academic, rich discussion :D
                                        >

                                        Yup. One which I hope, over time, motivates as much effort going into
                                        creating new-n-improved hypertext-control markup languages as currently
                                        goes into avoiding the hypertext constraint. I appreciate the debate,
                                        as it helps me figure out how to express the answers you're looking for.
                                        Specifically, what's wrong with a RESTful system (assuming one exists)
                                        based on IDLs?

                                        >
                                        > The "without a context" refers to dooming the IDLs just because they
                                        > are IDLs, in any possible situation. That said, I totally agree with
                                        > what you say, taken for granted the WSDL is an IDL used as an
                                        > out-of-band definition of flow for REST.
                                        >

                                        IDLs don't really provide a set of application-state transitions to
                                        choose from. REST is all about the API explaining *how* a collection of
                                        generic interfaces are coordinated into applications, expressed in-band
                                        and decoupled from resource state. I don't understand m2m solutions
                                        which start from the premise of moving the "how" out-of-band -- the
                                        systems being described are possible with REST and purport to have the
                                        same goals, so if that's the way forward all I require is falsification
                                        of the hypertext constraint, first. IDLs describe resource interfaces,
                                        not goal-driven application interfaces; if m2m is all about goals,
                                        then why start by removing their expression from the application states?

                                        >
                                        > As Mike pointed out, removing REST from the picture, and trying to
                                        > make WSDL a dynamically consumable, lean document, not oriented to
                                        > hypertext driven APIs but to messaging ones, not necessarily over
                                        > HTTP: is still WSDL as bad? Maybe it is good for something, in other
                                        > context.
                                        >

                                        It depends on what's best for the system being designed, sure. But,
                                        if the system is intended to exhibit the desirable characteristics
                                        induced by the application of the hypertext constraint, then why would
                                        it be just as good, or better, not to apply the hypertext constraint?
                                        A context where WSDL would be better, is one where coupling client to
                                        server around an out-of-band API has benefit. But, none of the
                                        examples I've seen of WSDL/WADL describe systems which wouldn't benefit
                                        from the decoupling provided by an in-band hypertext API, unless their
                                        scope is restricted to the point where REST isn't needed (or rational
                                        to purue).

                                        >
                                        > So, to answer your question, I guess no, it makes no sense to use a
                                        > IDL to represent REST Hypertext states transitions or flows. I can
                                        > almost call it an oxymoron. I hate RPC for services implementation,
                                        > still RPC may be good in some other situations. Just not for REST
                                        > anyway.
                                        >

                                        I wouldn't hesitate to set up a quickie RPC system for the internal
                                        purposes of a small office -- which wouldn't need to exhibit a fraction
                                        of the desirable characteristics induced by applying REST's constraints.
                                        I'd only apply the minimal set of constraints required to induce the
                                        characteristics needed within that context; XML-RPC may very well fit
                                        the bill, because I'd be more interested in completing the project than
                                        adding complexity to proactively solve problems I wouldn't even have.

                                        Once we're talking "Web Services" though, we're talking about the
                                        problems of extending a limited set of ubiquitous semantics across
                                        organizational boundaries over a flaky, anarchic network with global
                                        scale. Dealing with these problems adds complexity -- XML-RPC lacks
                                        such complexity, so it doesn't solve these problems well. CORBA solves
                                        a different set of problems while ignoring these. REST solves these
                                        problems with minimal added complexity. WS-* failed to solve these
                                        problems, by adding way too much complexity. So my money's still on
                                        REST for leveraging the Web's power to the benefit of any system which
                                        profits by being on the Web (extended a la ARRESTED or CREST, or not).

                                        -Eric
                                      • Jørn Wildt
                                        ... So lets try to consume the XForm dynamically and see what happens. Don t get me wrong - I am trying hard to figure out the best RESTfull API for my current
                                        Message 19 of 23 , Dec 24, 2010
                                        • 0 Attachment
                                          > > I guess that depends on how you consume the XForm.
                                          > Totally true. Knowing the XFORM up front will make you write a rigid
                                          > client. Same for WSDL.
                                          > Consuming the XFORM dynamically will make everybody happy.

                                          So lets try to consume the XForm dynamically and see what happens. Don't get
                                          me wrong - I am trying hard to figure out the best RESTfull API for my
                                          current project - not arguing against you, just trying to understand.

                                          The XForm has a model, it's submission data, and some user interface. I can
                                          easily see how the submission information could be consumed dynamically - I
                                          can extract the action URL, the method, and the media type at runtime and
                                          use those instead of hard coded values. The user interface part seems
                                          irrelevant for m2m systems, so lets ignore that (but maybe I am wrong?).

                                          It's the model that I find problematic. It's described by an XML schema and
                                          it seems to me that my client must have this schema baked into the code in
                                          order to work with it - how would it otherwise know how to mark-up the data
                                          needed to describe, for instance, a purchase order? This is where my
                                          understanding of a dynamic client breaks down. The client may have multiple
                                          known schemas to choose between - for instance Danish and German variations
                                          of purchase order schemas. But that's only semi-dynamic.

                                          Happy xmass everybody :-)

                                          /Jørn

                                          ----- Original Message -----
                                          From: "William Martinez Pomares" <wmartinez@...>
                                          To: <rest-discuss@yahoogroups.com>
                                          Sent: Thursday, December 23, 2010 8:01 PM
                                          Subject: [rest-discuss] Re: XForms vs. WSDL?


                                          Hi again.

                                          --- In rest-discuss@yahoogroups.com, Jørn Wildt <jw@...> wrote:
                                          > Yes, that's certainly one important difference. With SOAP/WSDL you are
                                          > given
                                          > everything up front and have to figure out what to use when. With REST you
                                          > are only served the links that fits the actual state. You cannot do the
                                          > last
                                          > with WSDL.

                                          Well, yes, you can. At least with WSDL (let's forget SOAP). WSDL is a web
                                          format, registered in IANA, and I can get it dynamically and consume it
                                          dynamically. Nobody does it because of tools, granted. The shame is on the
                                          tool designers.

                                          > I guess that depends on how you consume the XForm.

                                          Totally true. Knowing the XFORM up front will make you write a rigid client.
                                          Same for WSDL. Consuming the XFORM dynamically will make everybody happy. It
                                          is harder with WSDL, but possible too.
                                          Here the real difference is then the actual implementation, plus, I would
                                          say, XFORM is still light, and WSDL we may label it as "heavy".

                                          Cheers!

                                          William Martinez Pomares.
                                        • Jørn Wildt
                                          ... No, I was not saying it was a good thing (and I do see your smiley, thanks). I was trying to compare the two and understand why one is better than the
                                          Message 20 of 23 , Dec 26, 2010
                                          • 0 Attachment
                                            > >
                                            > > If you then add a list of links to XForms, the list would be much
                                            > > like the WSDL list of methods/messages.
                                            > >
                                            > You say that like it's a good thing? ;-)

                                            No, I was not saying it was a good thing (and I do see your smiley, thanks).
                                            I was trying to compare the two and understand why one is better than the
                                            other.

                                            My point is - if I can show that a WSDL and "something + XForm" are
                                            equivalent then why is XForm better than WSDL? I think the discussion so far
                                            have showed the differences. But it also seems that they to some degree are
                                            equivalent - and much of the difference lies in how they are consumed and
                                            the mindset of those implementing the client and server.

                                            Thanks for the feedback.

                                            /Jørn

                                            ----- Original Message -----
                                            From: "Eric J. Bowman" <eric@...>
                                            To: "Jørn Wildt" <jw@...>
                                            Cc: "Rest Discussion List" <rest-discuss@yahoogroups.com>
                                            Sent: Friday, December 24, 2010 1:13 AM
                                            Subject: Re: [rest-discuss] XForms vs. WSDL?


                                            Jørn Wildt wrote:
                                            >
                                            > I was reading Ian Robinsons "Using typed links to forms" (again, it's
                                            > a good read)
                                            >

                                            I disagree with the premise. REST's uniform interface requires generic
                                            media and data types. The example creates an application-specific media
                                            and data type (ordering one brand of coffee), where even domain-specific
                                            media and data types (ordering coffee) would be too fine-grained, where
                                            network-specific (generic to IP) media and data types are called for
                                            (ordering anything).

                                            Why not just use XForms forwards instead of backwards, using
                                            standardized data types and link relations like the thesis says? I
                                            don't understand how this would be less pragmatic than the example
                                            given, particularly to the extent of using pragmatism to justify
                                            deliberately avoiding the hypertext constraint in favor of increased
                                            coupling.

                                            Link relations aren't coupling when they're standardized, i.e. common
                                            knowledge at the IP layer across numerous protocols and data types. The
                                            difference is the key difference in REST -- the uniform interface is
                                            network-based, extended link relations are library-based (which is fine
                                            for domain-specific vocabulary, not for directing application flow by
                                            baking HTTP methods into them and such). Methods, headers, data types
                                            and link relations nobody's ever heard of before you minted them are
                                            *not* the same thing as the standardized uniform interface Roy's thesis
                                            describes.

                                            >
                                            > and document out of band how to post data to that link
                                            >

                                            Doesn't compute. The whole point of the hypertext constraint is that
                                            hypertext controls are used to document this in-band, relying on the
                                            common-knowledge processing model of ubiquitous media types. Maybe
                                            this other proposed architectural style has merit, I'm not judging,
                                            only stating that it can't be REST if there's no hypertext constraint.

                                            >
                                            > have an XForm at the end of the link and then use that information as
                                            > the online/inline/in-band documentation. I think that's quite a neat
                                            > idea, but it strikes me that it's getting awfull close to a WSDL spec.
                                            >

                                            Exactly. IDLs, and hypertext-driven APIs, aren't the same paradigm.
                                            It hadn't occurred to me that XForms could be repurposed as an IDL, but
                                            my advice is, don't. IDL-driven APIs are NOT REST.

                                            >
                                            > Both XForm and WSDL defines how to POST data adhering to a specific
                                            > XML schema.
                                            >

                                            Not exactly. IDLs are not self-documenting hypertext controls -- they
                                            cannot instruct a user-agent as to the default values, validate input
                                            (type=e-mail is one thing, black/whitelists are another) using code-on-
                                            demand; nor do they provide any mechanism to link to documentation (or
                                            render it outright as a pop-up) to inform the decision-making of the
                                            humans or machines (RDFa doesn't make much sense in an IDL) interacting
                                            with the API.

                                            >
                                            > If you then add a list of links to XForms, the list would be much
                                            > like the WSDL list of methods/messages.
                                            >

                                            You say that like it's a good thing? ;-) There are two approaches to
                                            the problem of distributing the object interface instead of distributing
                                            the object. One is to distribute a definition of your custom interface.
                                            The other is to use the distributed uniform interface, which is generic
                                            -- if all objects use the same interface, what's left to describe in
                                            an IDL?

                                            >
                                            > The rel="" types would specify WSDL message names.
                                            >

                                            In HTTP, REST's uniform interface includes, amongst other methods: GET,
                                            PUT, POST, PATCH and DELETE. If your interfaces are object-specific
                                            (hint, hint) then yeah, IDLs make sense, but I don't know how you start
                                            from tunneling custom methods (expressed as link relations) over POST
                                            and arrive at REST.

                                            >
                                            > In all we could have an HTML 5 list like the one below and call it
                                            > the WSDL method list:
                                            >
                                            > <dl>
                                            > <dt><a rel="" type="" href="">Title</a></dt>
                                            > <dd>Description</dd>
                                            > </dl>
                                            >
                                            > Each of the achors then points to an XForm which in turn points to an
                                            > XML schema definition and defines POST urls - just like WSDL does.
                                            >
                                            > Is this good or bad? Is it better or worse than WSDL and WADL? Other
                                            > opinions?
                                            >

                                            I really have no basis for comparing non-RESTful approaches. REST is a
                                            hypertext-driven architectural style based on standardized media types
                                            and standardized link relations. While extended link relations may be
                                            used to inform m2m decision-making, if the semantics of the interaction
                                            between connectors is that you can GET something and PUT it back then
                                            just use rel='edit' instead of defining an unlimited number of link
                                            relations to describe resource type (a server-side concern) to the
                                            client in lieu of using standardized hypertext controls.

                                            Note that rel='edit' says nothing about HTTP methods, or even HTTP,
                                            though. If you're assuming it means PUT, I have no idea how you'd
                                            reach that conclusion, even if the media type were application/atom+xml,
                                            because only a hypertext control communicates method to me. There's
                                            nothing in the communication between connectors which says "RFC 5023 in
                                            use". Only hypertext controls provide such instructions, which may be
                                            to GET the rel='edit'...

                                            Or, I may PATCH that resource -- but this is communicated through the
                                            hypertext representation, including the Allow and Accept(-*) headers.
                                            One hypertext control indicates that the entire "instance" (to stick
                                            with XForms) may be PUT as application/atom+xml, while another hypertext
                                            control indicates that categories may be PATCHed using an instance of
                                            application/atomcat+xml -- but this has no bearing on the link relation!

                                            I have no clue how any IDL- or schema-based approach supports the above
                                            paragraph, except as part of an API being driven by out-of-band
                                            information. When folks start talking about RESTful IDLs, schemae and
                                            overloaded link relations, my reaction is WTF are you people even
                                            *talking* about, as I've mentioned before. My snappy comeback, is why
                                            not just use rel='{HTTP method}' and have done with it? Things that
                                            are not hypertext controls:

                                            IDLs (even with a registered media type)
                                            media type definitions (registration doesn't indicate suitability)
                                            schemas (even with a registered media type)
                                            link relations (even when standardized)

                                            These things have their place, and I've even mentioned how IDLs could
                                            be used as a response to OPTIONS requests, but they are *not*
                                            substitutes for the hypertext constraint. Inferring things out-of-band
                                            bad, self-documenting hypertext APIs good.

                                            -Eric
                                          • Jørn Wildt
                                            Here comes som ramblings on forms and xforms, trying to understand what has been said on this list. ... Are you then saying that it is impossible to work with
                                            Message 21 of 23 , Dec 26, 2010
                                            • 0 Attachment
                                              Here comes som ramblings on forms and xforms, trying to understand what has
                                              been said on this list.

                                              > Methods, headers, data types
                                              > and link relations nobody's ever heard of before you minted them are
                                              > *not* the same thing as the standardized uniform interface Roy's thesis
                                              > describes.

                                              Are you then saying that it is impossible to work with domain specific
                                              models in REST? No one is ever going to standardize, say, a data format for
                                              yoga positions or similar obscure domains. Are we then disallowed to use the
                                              internet and REST for such domains? The same applies to link relations -
                                              what if there is no relation for a link to "The third normative yoga
                                              position of the current position" (which probably don't exists, but
                                              hopefully you get my point)? In following I'll try to give my impression of
                                              what I think you think ... let's see if I get your point.

                                              We have had such discussions before and your proposal was, as I remember it,
                                              to use html forms. See
                                              http://tech.groups.yahoo.com/group/rest-discuss/message/17057 I guess the
                                              same goes here again: use xhtml and html forms to describe how data is
                                              posted instead of minting your own media types. Then annotate the <input>
                                              elements with a "property" attribute that expresses the semantics of the
                                              element. Like for instance <input property="'foaf:name"
                                              name="some-irrelvant-serverside-variable-name"/>.

                                              So at runtime my client can discover the html form and look for the element
                                              with property="foaf:name" in order to transmit the "name" of the data. Which
                                              is not the same as looking for the element with
                                              name="some-irrelvant-serverside-variable-name" - or rather, knowing ahead of
                                              time, that "name" should be encoded as
                                              "some-irrelvant-serverside-variable-name".

                                              One way to understand this is as a decoupling of format and semantics. The
                                              semantics describe "this is a name (foaf:name)" whereas the format describes
                                              "the name most be encoded as some-irrelvant-serverside-variable-name". We
                                              could even go one step further and check to see if the "name" input is not
                                              there, and, if not, then, well, you are not supposed to update it. Is this a
                                              proper understanding of what you are saying?

                                              But sometimes it makes more sense to post XML data (at least for me). I am
                                              not saying "mint a new media type", all I want it to send some more complex
                                              data structures than key/value pairs handles without bending over
                                              backwards - and send that using application/xml. This is where XForm comes
                                              in. With XForms we can describe the input XML format/model and using the
                                              html user controls associated with XForms we can do like you did with xhtml
                                              forms and annotate the input elements with property="foaf:name" (or
                                              similar).

                                              Right?

                                              /Jørn
                                            • Justin Cormack
                                              No no, you are not supposed to know about the model directly, the interface bit is what you interact with, these are the hypertext controls. So you do need
                                              Message 22 of 23 , Dec 28, 2010
                                              • 0 Attachment
                                                No no, you are not supposed to know about the model directly, the
                                                "interface bit" is what you interact with, these are the hypertext
                                                controls. So you do need these for M2M applications of XForms too. The
                                                new model is opaque...

                                                Justin

                                                On Fri, 2010-12-24 at 23:11 +0100, Jørn Wildt wrote:
                                                >
                                                > It's the model that I find problematic. It's described by an XML
                                                > schema and
                                                > it seems to me that my client must have this schema baked into the
                                                > code in
                                                > order to work with it - how would it otherwise know how to mark-up the
                                                > data
                                                > needed to describe, for instance, a purchase order? This is where my
                                                > understanding of a dynamic client breaks down. The client may have
                                                > multiple
                                                > known schemas to choose between - for instance Danish and German
                                                > variations
                                                > of purchase order schemas. But that's only semi-dynamic.
                                                >
                                                > Happy xmass everybody :-)
                                                >
                                                > /Jørn
                                                >
                                                > ----- Original Message -----
                                                > From: "William Martinez Pomares" <wmartinez@...>
                                                > To: <rest-discuss@yahoogroups.com>
                                                > Sent: Thursday, December 23, 2010 8:01 PM
                                                > Subject: [rest-discuss] Re: XForms vs. WSDL?
                                                >
                                                > Hi again.
                                                >
                                                > --- In rest-discuss@yahoogroups.com, Jørn Wildt <jw@...> wrote:
                                                > > Yes, that's certainly one important difference. With SOAP/WSDL you
                                                > are
                                                > > given
                                                > > everything up front and have to figure out what to use when. With
                                                > REST you
                                                > > are only served the links that fits the actual state. You cannot do
                                                > the
                                                > > last
                                                > > with WSDL.
                                                >
                                                > Well, yes, you can. At least with WSDL (let's forget SOAP). WSDL is a
                                                > web
                                                > format, registered in IANA, and I can get it dynamically and consume
                                                > it
                                                > dynamically. Nobody does it because of tools, granted. The shame is on
                                                > the
                                                > tool designers.
                                                >
                                                > > I guess that depends on how you consume the XForm.
                                                >
                                                > Totally true. Knowing the XFORM up front will make you write a rigid
                                                > client.
                                                > Same for WSDL. Consuming the XFORM dynamically will make everybody
                                                > happy. It
                                                > is harder with WSDL, but possible too.
                                                > Here the real difference is then the actual implementation, plus, I
                                                > would
                                                > say, XFORM is still light, and WSDL we may label it as "heavy".
                                                >
                                                > Cheers!
                                                >
                                                > William Martinez Pomares.
                                                >
                                                >
                                                >
                                                >
                                                >
                                              • Jørn Wildt
                                                ... Doh? But what s the model for then? I can see that I can use the hypertext controls just like in HTML forms. So what is the model used for, except for
                                                Message 23 of 23 , Dec 28, 2010
                                                • 0 Attachment
                                                  > No no, you are not supposed to know about the model directly, the
                                                  > "interface bit" is what you interact with, these are the hypertext
                                                  > controls. So you do need these for M2M applications of XForms too. The
                                                  > new model is opaque...

                                                  Doh? But what's the model for then? I can see that I can use the hypertext
                                                  controls just like in HTML forms. So what is the model used for, except for
                                                  specifying submission details?

                                                  Thanks, Jørn

                                                  ----- Original Message -----
                                                  From: "Justin Cormack" <justin@...>
                                                  To: <rest-discuss@yahoogroups.com>
                                                  Sent: Tuesday, December 28, 2010 12:50 PM
                                                  Subject: Re: [rest-discuss] Re: XForms vs. WSDL?


                                                  > No no, you are not supposed to know about the model directly, the
                                                  > "interface bit" is what you interact with, these are the hypertext
                                                  > controls. So you do need these for M2M applications of XForms too. The
                                                  > new model is opaque...
                                                  >
                                                  > Justin
                                                  >
                                                  > On Fri, 2010-12-24 at 23:11 +0100, Jørn Wildt wrote:
                                                  >>
                                                  >> It's the model that I find problematic. It's described by an XML
                                                  >> schema and
                                                  >> it seems to me that my client must have this schema baked into the
                                                  >> code in
                                                  >> order to work with it - how would it otherwise know how to mark-up the
                                                  >> data
                                                  >> needed to describe, for instance, a purchase order? This is where my
                                                  >> understanding of a dynamic client breaks down. The client may have
                                                  >> multiple
                                                  >> known schemas to choose between - for instance Danish and German
                                                  >> variations
                                                  >> of purchase order schemas. But that's only semi-dynamic.
                                                  >>
                                                  >> Happy xmass everybody :-)
                                                  >>
                                                  >> /Jørn
                                                  >>
                                                  >> ----- Original Message -----
                                                  >> From: "William Martinez Pomares" <wmartinez@...>
                                                  >> To: <rest-discuss@yahoogroups.com>
                                                  >> Sent: Thursday, December 23, 2010 8:01 PM
                                                  >> Subject: [rest-discuss] Re: XForms vs. WSDL?
                                                  >>
                                                  >> Hi again.
                                                  >>
                                                  >> --- In rest-discuss@yahoogroups.com, Jørn Wildt <jw@...> wrote:
                                                  >> > Yes, that's certainly one important difference. With SOAP/WSDL you
                                                  >> are
                                                  >> > given
                                                  >> > everything up front and have to figure out what to use when. With
                                                  >> REST you
                                                  >> > are only served the links that fits the actual state. You cannot do
                                                  >> the
                                                  >> > last
                                                  >> > with WSDL.
                                                  >>
                                                  >> Well, yes, you can. At least with WSDL (let's forget SOAP). WSDL is a
                                                  >> web
                                                  >> format, registered in IANA, and I can get it dynamically and consume
                                                  >> it
                                                  >> dynamically. Nobody does it because of tools, granted. The shame is on
                                                  >> the
                                                  >> tool designers.
                                                  >>
                                                  >> > I guess that depends on how you consume the XForm.
                                                  >>
                                                  >> Totally true. Knowing the XFORM up front will make you write a rigid
                                                  >> client.
                                                  >> Same for WSDL. Consuming the XFORM dynamically will make everybody
                                                  >> happy. It
                                                  >> is harder with WSDL, but possible too.
                                                  >> Here the real difference is then the actual implementation, plus, I
                                                  >> would
                                                  >> say, XFORM is still light, and WSDL we may label it as "heavy".
                                                  >>
                                                  >> Cheers!
                                                  >>
                                                  >> William Martinez Pomares.
                                                  >>
                                                  >>
                                                  >>
                                                  >>
                                                  >>
                                                  >
                                                  >
                                                  >
                                                Your message has been successfully submitted and would be delivered to recipients shortly.