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

Interface definition languages and service registries for REST services

Expand Messages
  • Olivier Pernet
    Hi, I m fairly new to all things REST (and Web Services in general), but I do have some questions for you. Namely: - What do you think of the idea of having an
    Message 1 of 23 , Aug 2, 2007
    • 0 Attachment
      Hi,

      I'm fairly new to all things REST (and Web Services in general), but I
      do have some questions for you. Namely:

      - What do you think of the idea of having an interface definition
      language for REST services ? It seems some people outright reject the
      idea, while others support it in the form of WADL.
      It seems to me something like that would be nice to have, allowing for
      example Yahoo, Google and Microsoft to agree on a unified API for
      searches, that would be published using the IDL of choice. Client
      could then switch fairly easily from an implementation to another.
      Which leads to my second question...

      - Is there any ongoing attempt at establishing a standard for service
      registries ? If we were to have that kind of domain-specific
      standardized services, it would probably be interesting to have
      registries of interesting service interfaces along with running
      implementations. Which could be automatically tested for liveness by
      the registry, possibly using information from the IDL (testing
      published resources actually are there and respond to advertised
      verbs, etc).

      Sorry if this sound very naive, as I said, I'm a newcomer. I did read
      the previous thread about WADL but it seemed to drift to a discussion
      of the merits of WADL itself and not IDLs for REST in general.
      --
      Olivier Pernet

      We are the knights who say
      echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
    • Josh Sled
      ... It d be nice to have the ideas of HTML forms influence software-to-software HTTP-based-API design. The idea that if instead of hard-coding the
      Message 2 of 23 , Aug 2, 2007
      • 0 Attachment
        "Olivier Pernet" <o.pernet@...> writes:
        > - What do you think of the idea of having an interface definition
        > language for REST services ? It seems some people outright reject the

        It'd be nice to have the ideas of HTML forms influence software-to-software
        HTTP-based-API design. The idea that if instead of hard-coding the
        query-parameters that a resource expects to see GET or POSTed, a previous GET
        might have an in-band form that describes such parameters, for the software
        to construct. The idea that services – in the same ways that browsers do –
        benefit from starting from http://api.flickr.yahoo.com/ and traversing
        expected representations, rather than hard-coding URLs...


        > example Yahoo, Google and Microsoft to agree on a unified API for
        > searches, that would be published using the IDL of choice. Client

        Why would they want to do that?


        At the same time, one could imagine many of the blog engines of the world
        publishing a little fragment that looked something like:

        <!-- ... -->
        <form API:id="archive-content-search" method="GET" action="./search">
        <input type="text" name="q"/><input type="submit" value="Search!"/>
        </form>
        <!-- ... -->


        > - Is there any ongoing attempt at establishing a standard for service
        > registries ? If we were to have that kind of domain-specific
        > standardized services, it would probably be interesting to have
        [...]

        ETOO_MUCH_HYPOTHESISING.


        > We are the knights who say
        > echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc

        Heh heh. :)

        --
        ...jsled
        http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
      • Stefan Tilkov
        ... http://bitworking.org/news/193/Do-we-need-WADL ... We have one failed approach (with UDDI) already; not sure why we d need another one. For enterprisey
        Message 3 of 23 , Aug 3, 2007
        • 0 Attachment
          On Aug 3, 2007, at 3:41 AM, Olivier Pernet wrote:

          > Hi,
          >
          > I'm fairly new to all things REST (and Web Services in general), but I
          > do have some questions for you. Namely:
          >
          > - What do you think of the idea of having an interface definition
          > language for REST services ? It seems some people outright reject the
          > idea, while others support it in the form of WADL.
          > It seems to me something like that would be nice to have, allowing for
          > example Yahoo, Google and Microsoft to agree on a unified API for
          > searches, that would be published using the IDL of choice. Client
          > could then switch fairly easily from an implementation to another.
          > Which leads to my second question...
          >
          >
          http://bitworking.org/news/193/Do-we-need-WADL
          > - Is there any ongoing attempt at establishing a standard for service
          > registries ? If we were to have that kind of domain-specific
          > standardized services, it would probably be interesting to have
          > registries of interesting service interfaces along with running
          > implementations. Which could be automatically tested for liveness by
          > the registry, possibly using information from the IDL (testing
          > published resources actually are there and respond to advertised
          > verbs, etc).
          >
          >
          We have one failed approach (with UDDI) already; not sure why we'd
          need another one.
          For enterprisey (governance) aspects, some thoughts here:
          http://www.innoq.com/blog/st/2007/07/26/governance_and_rest.html

          > Sorry if this sound very naive, as I said, I'm a newcomer. I did read
          > the previous thread about WADL but it seemed to drift to a discussion
          > of the merits of WADL itself and not IDLs for REST in general.
          > --
          > Olivier Pernet
          >
          > We are the knights who say
          > echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
          >
          :-)
        • Story Henry
          ... Forms indeed are a key piece that needs to be looked at. I have found it inspiring to think of forms as questions available for the user agent to answer.
          Message 4 of 23 , Aug 3, 2007
          • 0 Attachment
            On 3 Aug 2007, at 04:42, Josh Sled wrote:
            > "Olivier Pernet" <o.pernet@...> writes:
            >> - What do you think of the idea of having an interface definition
            >> language for REST services ? It seems some people outright reject the
            >
            > It'd be nice to have the ideas of HTML forms influence software-to-
            > software
            > HTTP-based-API design. The idea that if instead of hard-coding the
            > query-parameters that a resource expects to see GET or POSTed, a
            > previous GET
            > might have an in-band form that describes such parameters, for the
            > software
            > to construct. The idea that services – in the same ways that
            > browsers do –
            > benefit from starting from http://api.flickr.yahoo.com/ and traversing
            > expected representations, rather than hard-coding URLs...

            Forms indeed are a key piece that needs to be looked at. I have found
            it inspiring to think of forms as questions available for the user
            agent to answer. By ticking a checkbox, entering text in a field,
            selecting a drop down menu, the user is answering a question
            explained in english to him, and binding variables to his answer.

            To make this more automatizable the questions have to be able to be
            asked in machine readable way that is both easy for humans and
            machines to understand, that is flexible and decentralised. The
            semantic web provides the machine readable decentralised vocabulary
            to describe the world, SPARQL the query language to ask it. To see
            how I first thought of it, have a quick read at "RESTFul Semantic Web
            Services"

            http://blogs.sun.com/bblfish/entry/restful_semantic_web_services

            That is a first shot. But it seems to be much more RESTful and easier
            to understand than the SOAP stack.


            >
            >> example Yahoo, Google and Microsoft to agree on a unified API for
            >> searches, that would be published using the IDL of choice. Client
            >

            That is called SPARQL.

            > Why would they want to do that?
            >
            >
            > At the same time, one could imagine many of the blog engines of the
            > world
            > publishing a little fragment that looked something like:
            >
            > <!-- ... -->
            > <form API:id="archive-content-search" method="GET" action="./
            > search">
            > <input type="text" name="q"/><input type="submit"
            > value="Search!"/>
            > </form>
            > <!-- ... -->
            >
            >
            >> - Is there any ongoing attempt at establishing a standard for service
            >> registries ? If we were to have that kind of domain-specific
            >> standardized services, it would probably be interesting to have
            > [...]

            You no longer need standard registries. With SPARQL and the semantic
            web you have all you need.

            Now I am not absolutely sure of that statement to tell you the truth,
            because I have not used registries that much, so if you have a doubt
            please put forward a use case of a registry, and I'll try to show how
            I would do it .


            >
            > ETOO_MUCH_HYPOTHESISING.
            >
            >
            >> We are the knights who say
            >> echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
            >
            > Heh heh. :)

            :-)
          • Olivier Pernet
            ... Now that sound good. It s still an IDL isn t it ? It s just distributed directly by the service provider and is not exportable. But this and WADL are
            Message 5 of 23 , Aug 3, 2007
            • 0 Attachment
              On 8/3/07, Josh Sled <jsled@...> wrote:
              > "Olivier Pernet" <o.pernet@...> writes:
              > > - What do you think of the idea of having an interface definition
              > > language for REST services ? It seems some people outright reject the
              >
              > It'd be nice to have the ideas of HTML forms influence software-to-software
              > HTTP-based-API design. The idea that if instead of hard-coding the
              > query-parameters that a resource expects to see GET or POSTed, a previous GET
              > might have an in-band form that describes such parameters, for the software
              > to construct. The idea that services – in the same ways that browsers do –
              > benefit from starting from http://api.flickr.yahoo.com/ and traversing
              > expected representations, rather than hard-coding URLs...

              Now that sound good. It's still an IDL isn't it ? It's just
              distributed directly by the service provider and is not exportable.
              But this and WADL are different implementations of the same idea,
              aren't they?

              > > example Yahoo, Google and Microsoft to agree on a unified API for
              > > searches, that would be published using the IDL of choice. Client
              >
              > Why would they want to do that?

              OK, that sound a bit far-fetched. How about makers of blogging
              software agreeing on such a standard so that it's easier to
              - switch blogging engines
              - write software that extracts stuff outs of blogs

              > At the same time, one could imagine many of the blog engines of the world
              > publishing a little fragment that looked something like:
              >
              > <!-- ... -->
              > <form API:id="archive-content-search" method="GET" action="./search">
              > <input type="text" name="q"/><input type="submit" value="Search!"/>
              > </form>
              > <!-- ... -->
              [...]


              Thanks for the prompt replies !

              --
              Olivier Pernet

              We are the knights who say
              echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
            • Olivier Pernet
              ... Well, this makes a case against WADL, based on - experience with WSDL showing that people will want to generate code from it - the fact that current schema
              Message 6 of 23 , Aug 3, 2007
              • 0 Attachment
                On 8/3/07, Stefan Tilkov <stefan.tilkov@...> wrote:
                > On Aug 3, 2007, at 3:41 AM, Olivier Pernet wrote:
                >
                > > Hi,
                > >
                > > I'm fairly new to all things REST (and Web Services in general), but I
                > > do have some questions for you. Namely:
                > >
                > > - What do you think of the idea of having an interface definition
                > > language for REST services ? It seems some people outright reject the
                > > idea, while others support it in the form of WADL.
                > > It seems to me something like that would be nice to have, allowing for
                > > example Yahoo, Google and Microsoft to agree on a unified API for
                > > searches, that would be published using the IDL of choice. Client
                > > could then switch fairly easily from an implementation to another.
                > > Which leads to my second question...
                > >
                > >
                > http://bitworking.org/news/193/Do-we-need-WADL

                Well, this makes a case against WADL, based on
                - experience with WSDL showing that people will want to generate code from it
                - the fact that current schema description languages are not adequate
                ...all implementation issues, however important, IMHO.

                On the other hand, the OpenSearch format definitely is an IDL. It's a
                domain-specific IDL. So what ? It's a different implementation of the
                same basic idea. Now it may make a lot more sense to have narrower,
                domain-specific IDLs like that : it may make capturing semantics
                easier, and users of a search service are not going to switch to a
                stockquote service without changing their code anyway.

                Now comes the question : how does the domain-specific IDLs fit with
                the idea of having forms as IDLs ? As I see it, forms as IDLs are just
                a layer of indirection, while an full fledged IDL document may give
                more infomation. But maybe more information isn't needed.

                > > - Is there any ongoing attempt at establishing a standard for service
                > > registries ? If we were to have that kind of domain-specific
                > > standardized services, it would probably be interesting to have
                > > registries of interesting service interfaces along with running
                > > implementations. Which could be automatically tested for liveness by
                > > the registry, possibly using information from the IDL (testing
                > > published resources actually are there and respond to advertised
                > > verbs, etc).
                > >
                > >
                > We have one failed approach (with UDDI) already; not sure why we'd
                > need another one.
                > For enterprisey (governance) aspects, some thoughts here:
                > http://www.innoq.com/blog/st/2007/07/26/governance_and_rest.html

                Interesting. But I was more thinking about the public Web here, where
                having a starting point to get to service implementations could be
                more valuable that within a single entreprise (where you now more or
                less what is up and running).

                --
                Olivier Pernet

                We are the knights who say
                echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
              • Josh Sled
                ... Somewhat. AIUI, WADL is still a development-/compile-time description. Once you ve written software to the described API, you re tightly coupled to that
                Message 7 of 23 , Aug 3, 2007
                • 0 Attachment
                  "Olivier Pernet" <o.pernet@...> writes:
                  > On 8/3/07, Josh Sled <jsled@...> wrote:
                  >> "Olivier Pernet" <o.pernet@...> writes:
                  >> > - What do you think of the idea of having an interface definition
                  >> > language for REST services ? It seems some people outright reject the
                  >>
                  >> It'd be nice to have the ideas of HTML forms influence software-to-software
                  >> HTTP-based-API design. The idea that if instead of hard-coding the
                  >> query-parameters that a resource expects to see GET or POSTed, a previous GET
                  >> might have an in-band form that describes such parameters, for the software
                  >> to construct. The idea that services – in the same ways that browsers do –
                  >> benefit from starting from http://api.flickr.yahoo.com/ and traversing
                  >> expected representations, rather than hard-coding URLs...
                  >
                  > Now that sound good. It's still an IDL isn't it ? It's just
                  > distributed directly by the service provider and is not exportable.
                  > But this and WADL are different implementations of the same idea,
                  > aren't they?

                  Somewhat. AIUI, WADL is still a development-/compile-time description. Once
                  you've written software to the described API, you're tightly coupled to that
                  API. The other approach is a run-time, dynamic one. In particular, it moves
                  the application state transitions into hypermedia, which is one of the key
                  REST constraints. I still think there's room for an "IDL", but it's
                  "distributed" through the resources and their representation formats, rather
                  than a single up-front service-focused description document.

                  --
                  ...jsled
                  http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
                • Ernest Prabhakar
                  Hi Henry, ... Thanks! I ve added it to my REST Service Descriptions page: http://microformats.org/wiki/rest/description#Proposals.2FExamples Best, -- Ernie P.
                  Message 8 of 23 , Aug 3, 2007
                  • 0 Attachment
                    Hi Henry,

                    On Aug 3, 2007, at 1:24 AM, Story Henry wrote:

                    > To see how I first thought of it, have a quick read at "RESTFul
                    > Semantic Web
                    > Services"
                    >
                    > http://blogs.sun.com/bblfish/entry/restful_semantic_web_services
                    >
                    > That is a first shot. But it seems to be much more RESTful and easier
                    > to understand than the SOAP stack.

                    Thanks! I've added it to my REST Service Descriptions page:

                    http://microformats.org/wiki/rest/description#Proposals.2FExamples

                    Best,
                    -- Ernie P.
                  • Steve Loughran
                    ... Olivier, 1. signature!=interface. The original definition by D.L. Parnas defined interface as signature+semantics. In the absence of a formal language to
                    Message 9 of 23 , Aug 6, 2007
                    • 0 Attachment
                      On 8/3/07, Olivier Pernet <o.pernet@...> wrote:
                      > Hi,
                      >
                      > I'm fairly new to all things REST (and Web Services in general), but I
                      > do have some questions for you. Namely:
                      >
                      > - What do you think of the idea of having an interface definition
                      > language for REST services ? It seems some people outright reject the
                      > idea, while others support it in the form of WADL.
                      > It seems to me something like that would be nice to have, allowing for
                      > example Yahoo, Google and Microsoft to agree on a unified API for
                      > searches, that would be published using the IDL of choice. Client
                      > could then switch fairly easily from an implementation to another.
                      > Which leads to my second question...

                      Olivier,

                      1. signature!=interface. The original definition by D.L. Parnas
                      defined interface as signature+semantics. In the absence of a formal
                      language to define the semantics of a communication, all you are left
                      with is things to try and stabilise the signature (WSDL) or to
                      describe some of the communications protocol.

                      2. WSDL encouraged an explosion of service interfaces, which, as we
                      all know, was a mistake. Why not not just assume that everyone and
                      everything will adopt APP and built your services to integrate with
                      that?


                      >
                      > - Is there any ongoing attempt at establishing a standard for service
                      > registries ? If we were to have that kind of domain-specific
                      > standardized services, it would probably be interesting to have
                      > registries of interesting service interfaces along with running
                      > implementations. Which could be automatically tested for liveness by
                      > the registry, possibly using information from the IDL (testing
                      > published resources actually are there and respond to advertised
                      > verbs, etc).

                      Oh olivier, we dont want to go there again.

                      > Sorry if this sound very naive, as I said, I'm a newcomer. I did read
                      > the previous thread about WADL but it seemed to drift to a discussion
                      > of the merits of WADL itself and not IDLs for REST in general.
                      > --

                      I think you need consensus on what constitutes an interface before you
                      can worry about an IDL.
                    • Mike Schinkel
                      Steve Loughran ... Agreed, as implemented. ... Doesn t that just push the problem elsewhere? Now we have atom being used for lots of different things with the
                      Message 10 of 23 , Aug 7, 2007
                      • 0 Attachment
                        Steve Loughran
                        > 2. WSDL encouraged an explosion of service interfaces, which,
                        > as we all know, was a mistake.

                        Agreed, as implemented.

                        > Why not not just assume that
                        > everyone and everything will adopt APP and built your
                        > services to integrate with that?

                        Doesn't that just push the problem elsewhere? Now we have atom being used
                        for lots of different things with the confusion moved up the stack. Seems
                        like we are trading one problem for another.

                        --
                        -Mike Schinkel
                        organizer@...
                        http://atlanta-web.org
                        404-276-1276 (cell)

                        P.S. Also, accorrding to Joe Gregorio, it's "AtomPub" not "APP" '-)
                      • Nic
                        ... But you have added a simple constraint. use APP -- Nic Ferrier http://prooveme.com - easy, simple, certificated OpenID
                        Message 11 of 23 , Aug 7, 2007
                        • 0 Attachment
                          "Mike Schinkel" <mikeschinkel@...> writes:

                          > Doesn't that just push the problem elsewhere? Now we have atom being used
                          > for lots of different things with the confusion moved up the stack. Seems
                          > like we are trading one problem for another.

                          But you have added a simple constraint.

                          "use APP"

                          --
                          Nic Ferrier
                          http://prooveme.com - easy, simple, certificated OpenID
                        • Mike Schinkel
                          ... I don t follow your point... -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org -
                          Message 12 of 23 , Aug 7, 2007
                          • 0 Attachment
                            Nic Ferrier wrote:
                            > > Doesn't that just push the problem elsewhere? Now we have
                            > atom being
                            > > used for lots of different things with the confusion moved up the
                            > > stack. Seems like we are trading one problem for another.
                            >
                            > But you have added a simple constraint.
                            >
                            > "use APP"

                            I don't follow your point...

                            --
                            -Mike Schinkel
                            http://www.mikeschinkel.com/blogs/
                            http://www.welldesignedurls.org
                            http://atlanta-web.org - http://t.oolicio.us
                          • A. Pagaltzis
                            ... If Atompub is a close enough match to your problem domain, then that part of the confusion gets resolved; the *rest* is pushed up the stack, but it’s a
                            Message 13 of 23 , Aug 9, 2007
                            • 0 Attachment
                              * Mike Schinkel <mikeschinkel@...> [2007-08-08 03:30]:
                              > Steve Loughran
                              > > Why not not just assume that everyone and everything will
                              > > adopt APP and built your services to integrate with that?
                              >
                              > Doesn't that just push the problem elsewhere? Now we have atom
                              > being used for lots of different things with the confusion
                              > moved up the stack. Seems like we are trading one problem for
                              > another.

                              If Atompub is a close enough match to your problem domain, then
                              that part of the confusion gets resolved; the *rest* is pushed up
                              the stack, but it’s a *smaller* confusion than what you started
                              with. You no longer need to define what your operations are (they
                              are those that Atompub defines); only what the things mean that
                              you are operating on.

                              Regards,
                              --
                              Aristotle Pagaltzis // <http://plasmasturm.org/>
                            • A. Pagaltzis
                              Hi Olivier, ... I think there is a conflation of ideas here. My most widely cited weblog entry (that started life as a post on this list) goes into this:
                              Message 14 of 23 , Aug 9, 2007
                              • 0 Attachment
                                Hi Olivier,

                                * Olivier Pernet <o.pernet@...> [2007-08-03 17:00]:
                                > What do you think of the idea of having an interface definition
                                > language for REST services ? It seems some people outright
                                > reject the idea, while others support it in the form of WADL.

                                I think there is a conflation of ideas here. My most widely cited
                                weblog entry (that started life as a post on this list) goes into
                                this:

                                http://plasmasturm.org/log/460/

                                Basically, “these are not your father’s interface descriptions.”

                                I think WADL is mistaken, but I don’t think the concept of
                                generating code from a description needs to be abandoned. I just
                                think it needs to describe different things than an IDL as we
                                know it describes.

                                Specifically, I think what we need is a description language that
                                could be implemented as a vocabulary to be embedded into a
                                Relax NG or Schematron schema, which identifies which parts of a
                                document conforming to that schema are links, or forms, and
                                specifies what semantics this form or link implies; eg. the
                                Relax NG grammar for Atompub in XML syntax form contains, among
                                other things, this:

                                <element name="app:collection">
                                <ref name="appCommonAttributes"/>
                                <attribute name="href">
                                <ref name="atomURI"/>
                                </attribute>
                                <interleave>
                                <ref name="atomTitle"/>
                                <zeroOrMore>
                                <ref name="appAccept"/>
                                </zeroOrMore>
                                <zeroOrMore>
                                <ref name="appCategories"/>
                                </zeroOrMore>
                                <zeroOrMore>
                                <ref name="extensionSansTitleElement"/>
                                </zeroOrMore>
                                </interleave>
                                </element>

                                We could turn this grammar into a description language for a
                                RESTful system by saying something like the following, where I’m
                                going to zoom on the `href` attribute part:

                                <attribute name="href">
                                <ref name="atomURI"/>
                                <ridl:link>
                                <ridl:request>
                                <ridl:method name="GET"/>
                                <ridl:response content-type="application/atom+xml"/>
                                </ridl:method>
                                <ridl:request>
                                <ridl:method name="POST">
                                <ridl:content-type name="application/atom+xml;entry"/>
                                <ridl:response content-type="application/atom+xml;entry">
                                </ridl:request>
                                <ridl:request>
                                <ridl:method name="POST">
                                <ridl:content-type name="*/*"/>
                                <ridl:response content-type="application/atom+xml;entry">
                                </ridl:request>
                                </ridl:link>
                                </attribute>

                                The “RIDL” vocabulary I used here is highly incomplete, of
                                course, and the nesting might come out differently also, but it’s
                                a sketch that demonstrates the sort of approach I envision. There
                                would be a corresponding `ridl:form` element, and a lot more
                                elements specifying the pre- and post-conditions each particular
                                request/response cycle must fulfill.

                                Assuming we have all these facilities, then you could take
                                RIDL-annotated `atomsvc.rng` and `atom.rng` grammars and run them
                                through a code generator that will construct out a library which
                                presents an API based on the semantics of Atompub Service and
                                Category Documents and Atom Feed Documents.

                                But which knows nothing about the URIs your Atompub service uses.

                                Nor does it know anything about Atompub at all, of course.

                                The library just follows links and submits forms as you make
                                calls against its API. Of course you would then have to couple it
                                with some hand-written code to fill in the gaps, namely why and
                                when to make the requests that the annotation specifies as
                                acceptable – the knowledge of what the levers in an Atompub
                                service *mean*, rather than just what the levers are.

                                What we have here is much like WADL, but rather than being a
                                stand-alone IDL telling you which URIs to make what requests
                                against, it is embedded in a grammar such that it explains where
                                to find the relevant URIs in a representation that will be
                                returned by the service at run time, *and then* what requests to
                                make against *those*.

                                Regards,
                                --
                                Aristotle Pagaltzis // <http://plasmasturm.org/>
                              • Mike Schinkel
                                ... Oh, I concur that AtomPub is useful in many contexts but, as you imply, not all. Advocating it to be only solution needed is shortsighted, IMO. Don t you
                                Message 15 of 23 , Aug 10, 2007
                                • 0 Attachment
                                  A. Pagaltzis wrote:
                                  > If Atompub is a close enough match to your problem domain,
                                  > then that part of the confusion gets resolved; the *rest* is
                                  > pushed up the stack, but it's a *smaller* confusion than what
                                  > you started with. You no longer need to define what your
                                  > operations are (they are those that Atompub defines); only
                                  > what the things mean that you are operating on.

                                  Oh, I concur that AtomPub is useful in many contexts but, as you imply, not
                                  all. Advocating it to be only solution needed is shortsighted, IMO. Don't
                                  you agree?

                                  --
                                  -Mike Schinkel
                                  http://www.mikeschinkel.com/blogs/
                                  http://www.welldesignedurls.org
                                  http://atlanta-web.org - http://t.oolicio.us
                                • 'A. Pagaltzis'
                                  ... With a caveat; namely that I think Atompub is applicable to many more contexts than people might realise. So I think it worthwhile to tell them to try it
                                  Message 16 of 23 , Aug 10, 2007
                                  • 0 Attachment
                                    * Mike Schinkel <mikeschinkel@...> [2007-08-10 20:05]:
                                    > A. Pagaltzis wrote:
                                    > > If Atompub is a close enough match to your problem domain,
                                    > > then that part of the confusion gets resolved; the *rest* is
                                    > > pushed up the stack, but it's a *smaller* confusion than what
                                    > > you started with. You no longer need to define what your
                                    > > operations are (they are those that Atompub defines); only
                                    > > what the things mean that you are operating on.
                                    >
                                    > Oh, I concur that AtomPub is useful in many contexts but, as
                                    > you imply, not all. Advocating it to be only solution needed
                                    > is shortsighted, IMO. Don't you agree?

                                    With a caveat; namely that I think Atompub is applicable to many
                                    more contexts than people might realise. So I think it worthwhile
                                    to tell them to try it first before they do anything else.

                                    But yeah, I’m not a dogmatist. If they’ve given it thought and
                                    found it really *is* a bad fit, then absolutely, insisting to
                                    shoehorn their problem into Atompub would be silly.

                                    Regards,
                                    --
                                    Aristotle Pagaltzis // <http://plasmasturm.org/>
                                  • Mike Schinkel
                                    ... And in the case where it is a good fit, there is then a need to again define the interacts for each use-case (beyond the nomimal case of publish. ) One
                                    Message 17 of 23 , Aug 10, 2007
                                    • 0 Attachment
                                      > With a caveat; namely that I think Atompub is applicable to
                                      > many more contexts than people might realise. So I think it
                                      > worthwhile to tell them to try it first before they do anything else.

                                      And in the case where it is a good fit, there is then a need to again define
                                      the interacts for each use-case (beyond the nomimal case of "publish.")

                                      One thing I dislike about AtomPub, and I know I'm probably in the minority
                                      here, is it requires special tools to interact with vs. just having a
                                      browser, and it requires web services be created in addition to web pages.
                                      I'd really advocate for exposing webservices as a default case via semantic
                                      HTML instead of AtomPub though AtomPub could be the default second case in
                                      "the world according to Mike." I thinking it should be a best practice to
                                      that when web developers build a website it should also double as a
                                      REST-based web service. That would take web services out of the realm of
                                      "mystical" and makes it possible for less skilled people to interact with
                                      them and to see the value in them. And I was glad to see that the book
                                      RESTful Web Services advocated that approach too (though not as strongly as
                                      I would have liked.)

                                      JMTCW anyway.

                                      --
                                      -Mike Schinkel
                                      http://www.mikeschinkel.com/blogs/
                                      http://www.welldesignedurls.org
                                      http://atlanta-web.org - http://t.oolicio.us
                                    • 'A. Pagaltzis'
                                      ... Sure, but they’ll have to define those anyway. Atompub just takes care of predefining the lower-level machinery so it doesn’t have to be reinvented
                                      Message 18 of 23 , Aug 11, 2007
                                      • 0 Attachment
                                        * Mike Schinkel <mikeschinkel@...> [2007-08-11 05:25]:
                                        > > With a caveat; namely that I think Atompub is applicable to
                                        > > many more contexts than people might realise. So I think it
                                        > > worthwhile to tell them to try it first before they do
                                        > > anything else.
                                        >
                                        > And in the case where it is a good fit, there is then a need to
                                        > again define the interacts for each use-case (beyond the
                                        > nomimal case of "publish.")

                                        Sure, but they’ll have to define those anyway. Atompub just takes
                                        care of predefining the lower-level machinery so it doesn’t have
                                        to be reinvented over and over by everyone who has similar needs.

                                        > One thing I dislike about AtomPub, and I know I'm probably in
                                        > the minority here, is it requires special tools to interact
                                        > with vs. just having a browser,

                                        Wait, first you’re telling me you don’t like one-size-fits-all
                                        advocacy for Atompub, then you tell me we should just shoehorn
                                        all apps into the browser? :-)

                                        Me, I hope that Atompub uptake is strong enough that we’ll see
                                        browsers expand to support everything required that one day we
                                        shall, in fact, be able to interact with many Atompub services
                                        with just a browser. (In fact, with XMLHttpRequest you already
                                        can. Several people are working on such Atompub clients.)

                                        I don’t mean just Atompub support here, btw; I mean general
                                        support for more of HTTP (like methods other than GET and POST –
                                        what a concept!), and markup languages like HTML5 that allow
                                        users to actually exploit this expanded support.

                                        > it requires web services be created in addition to web pages.
                                        >
                                        > I'd really advocate for exposing webservices as a default case
                                        > via semantic HTML instead of AtomPub

                                        How is that different? A WordPress blog has a public face and an
                                        admin area. Isn’t it really kind of incidental what kind of
                                        content types get exchanged on which half of the service?

                                        The important point is that no approach will remove this
                                        public-vs-editable segregation for most apps.

                                        And semantic HTML, uhm, good luck repairing HTML-as-she-is-spoke
                                        sufficiently that it becomes machine-consumable, in a reasonable
                                        timeframe. Not that I wouldn’t like that myself, but, while we
                                        may all gaze at the stars, we’re still down here in this gutter.

                                        Regards,
                                        --
                                        Aristotle Pagaltzis // <http://plasmasturm.org/>
                                      • Ernest Prabhakar
                                        Hi Mike, ... I would love to see someone define/build a hAtom version of AtomPub, that worked in standard web browsers: http://microformats.org/wiki/hatom Any
                                        Message 19 of 23 , Aug 11, 2007
                                        • 0 Attachment
                                          Hi Mike,

                                          On Aug 10, 2007, at 8:24 PM, Mike Schinkel wrote:
                                          One thing I dislike about AtomPub, and I know I'm probably in the minority
                                          here, is it requires special tools to interact with vs. just having a
                                          browser, and it requires web services be created in addition to web pages.
                                          I'd really advocate for exposing webservices as a default case via semantic
                                          HTML instead of AtomPub though AtomPub could be the default second case in
                                          "the world according to Mike."

                                          I would love to see someone define/build a hAtom version of AtomPub, that worked in standard web browsers:


                                          Any takers? :-)

                                          -- Ernie P.


                                        • Mike Schinkel
                                          ... Of course, but there are still many things in the use-case domain AtomPub doesn t address so we end up having to deal with those. Hence back to the same
                                          Message 20 of 23 , Aug 11, 2007
                                          • 0 Attachment
                                            A. Pagaltzis wrote:
                                            > Sure, but they'll have to define those anyway. Atompub just
                                            > takes care of predefining the lower-level machinery so it
                                            > doesn't have to be reinvented over and over by everyone who
                                            > has similar needs.

                                            Of course, but there are still many things in the use-case domain AtomPub
                                            doesn't address so we end up having to deal with those. Hence back to the
                                            same problem albeit higher up the stack.

                                            > Wait, first you're telling me you don't like
                                            > one-size-fits-all advocacy for Atompub, then you tell me we
                                            > should just shoehorn all apps into the browser? :-)

                                            You are putting words in my mouth, as usual. :)

                                            I didn't say that I didn't like the one-size-fits-all aspect, that aspect I
                                            do like; the uniform interface. What I was tryng to say is there will still
                                            be a need for use-case specifics and without some way to identify and codify
                                            those we'll end up with the same problem, albeit higher up the stack (Is
                                            there an echo in here? Am I repeating myself? :)

                                            > Me, I hope that Atompub uptake is strong enough that we'll
                                            > see browsers expand to support everything required that one
                                            > day we shall, in fact, be able to interact with many Atompub
                                            > services with just a browser.

                                            I have mixed feelings about that. Yes, I assume I would like browser
                                            support but frankly I find the browser support in IE7 of RSS disconcerting.
                                            When I go there I expect to see the RSS, not the RSS view although I can't
                                            exactly say why yet. It always frustrates me when I click a link on a
                                            Google search result page and realize that it was an RSS feed. If AtomPub
                                            proliferates for general purpose use, that could even get a lot worse.

                                            But what I do know is I strongly believe there should be only one primary
                                            format for the web, HTML. The fact is has stayed the primary interface for
                                            years from a user perspective is I believe one of the reasons the web has
                                            been so successful. Throw lots of complexity into the mix and it will just
                                            muddy everything.

                                            > (In fact, with XMLHttpRequest you already can.)

                                            Actually, that's not true. Browsers don't natively display things using
                                            XMLHttpRequest, it is a capability that needs to be programmed. By your
                                            logic then Java applets and in some browsers ActiveX controls can all be
                                            interacted with via a browser. Tell me, how many grandmas are interacting
                                            with XMLHttpRequest?

                                            > I don't mean just Atompub support here, btw; I mean general
                                            > support for more of HTTP (like methods other than GET and
                                            > POST - what a concept!), and markup languages like HTML5 that
                                            > allow users to actually exploit this expanded support.
                                            >

                                            That I concur with.

                                            > > it requires web services be created in addition to web pages.
                                            > >
                                            > > I'd really advocate for exposing webservices as a default case via
                                            > > semantic HTML instead of AtomPub
                                            >
                                            > How is that different? A WordPress blog has a public face and
                                            > an admin area. Isn't it really kind of incidental what kind
                                            > of content types get exchanged on which half of the service?

                                            The differences are:

                                            -- the requirement to develop seperately for multiple content types.
                                            -- the high liklihood that the two efforts will result in output lacking
                                            100% fidelity.
                                            -- the high liklihood that the web service won't be developed even though
                                            the web site is.
                                            -- that tools available for HTML, including browsers, will never in their
                                            entirety be available for AtomPub.
                                            -- the fact that the default interaction for users on the web is with
                                            content that behaves like HTML

                                            Having it be a best practice where building a website means building a web
                                            service will ensure many more web services actually get built. And we can
                                            see significant uptake if we just get CMS developers to consider this a best
                                            practice. I'm currently working in Drupal and I plan to look at how Drupal
                                            can be made to offer web services by default.

                                            The only way it is viable in my world view is if the CMS that is generating
                                            the content type generates them with 100% fidelity without user/admin
                                            involvement; i.e. the content in HTML is exactly the same as in AtomPub. For
                                            example, TurboGears does it that way. And even then, it doesn't allows
                                            someone to navigate the web service with a browser and be able to see w/o
                                            programming the data complete with links they can right-click to retrieve
                                            said information.

                                            > The important point is that no approach will remove this
                                            > public-vs-editable segregation for most apps.

                                            I don't understand your terminology.

                                            > And semantic HTML, uhm, good luck repairing
                                            > HTML-as-she-is-spoke sufficiently that it becomes
                                            > machine-consumable, in a reasonable timeframe.
                                            > wouldn't like that myself, but, while we may all gaze at the
                                            > stars, we're still down here in this gutter.

                                            You are looking at it wrong. We don't need to get everyone to convert all
                                            HTML content as we would need to in order to be able to make a clean slate
                                            HTML5 possible, we just need to have it evolve as a best practice with
                                            software like WordPress and Drupal leading the way. It's a win for those
                                            websites and CMS that implement it.
                                            We don't need 100% of the web for this to be useful. Each site that does it
                                            will be useful in its own right. Clearly the same is true for AtomPub; we
                                            don't have lots of existing AtomPub to convert either.

                                            That said, you mention that AtomPub handles things for you so you don't have
                                            to. I've read the AtomPub spec, although I don't know how awake I was
                                            reading it considering how long it is, and I didn't see anything earth
                                            shattering. I see AtomPub as a very valuable albeit specialty
                                            protocol/format. It seems you see it for general purpose use. Can you tell
                                            me specifically what it is about AtomPub that causes you to value its use
                                            outside the nominal case of publishing?

                                            Maybe it is a panacea and I just don't yet see it. Here's your chance,
                                            convert me.

                                            --
                                            -Mike Schinkel
                                            http://www.mikeschinkel.com/blogs/
                                            http://www.welldesignedurls.org
                                            http://atlanta-web.org - http://t.oolicio.us
                                          • Assaf Arkin
                                            ... I m wondering if hAtom would be the simplest thing that could possibly work. Do we really need to burden the client with the ceremonial stuffing of the
                                            Message 21 of 23 , Aug 11, 2007
                                            • 0 Attachment
                                              --- In rest-discuss@yahoogroups.com, Ernest Prabhakar
                                              <ernest.prabhakar@...> wrote:
                                              >
                                              > I would love to see someone define/build a hAtom version of AtomPub,
                                              > that worked in standard web browsers:
                                              >
                                              > http://microformats.org/wiki/hatom
                                              >
                                              > Any takers? :-)

                                              I'm wondering if hAtom would be the simplest thing that could possibly
                                              work. Do we really need to burden the client with the ceremonial
                                              stuffing of the envelope?

                                              Start by posing the title and content. An interesting feature of HTTP
                                              that's often ignored in favor of envelopes, is that you can use named
                                              parameters. If you can determine the blog's posting URL, which is
                                              fairly easy to do, you've covered the basics for WordPress, Blogger
                                              and MovableType. I think that's a good base to start with. Add
                                              authentication -- we're doing this from the browser, after all -- and
                                              you also get the author metadata and access control.

                                              In response, the server will redirect you to a URL where you can
                                              update, publish and delete the post. Now this being the Browsable
                                              Web, we'll have to do with just two verbs.

                                              I think we already have enough commonality here to extract an
                                              interface that already works for a lot of people to handle all the
                                              common cases. That would be the microformat way of doing things, even
                                              if we don't involve hAtom directly.

                                              -- Assaf Arkin

                                              http://labnotes.org

                                              >
                                              > -- Ernie P.
                                              >
                                            • 'A. Pagaltzis'
                                              ... No, not the *same* problem – just the *application-specific* part of the problem. The common parts of the problem are factored out to Atompub. But
                                              Message 22 of 23 , Aug 12, 2007
                                              • 0 Attachment
                                                * Mike Schinkel <mikeschinkel@...> [2007-08-11 21:00]:
                                                > Of course, but there are still many things in the use-case
                                                > domain AtomPub doesn't address so we end up having to deal with
                                                > those. Hence back to the same problem albeit higher up the
                                                > stack.

                                                No, not the *same* problem – just the *application-specific* part
                                                of the problem. The common parts of the problem are factored out
                                                to Atompub.

                                                But that’s a given; Atompub is infrastructure, just like HTTP
                                                itself. The fact that Atompub alone is not enough to model the
                                                full semantics of the application is no more to the point than
                                                the fact that HTTP isn’t either. Yet I don’t see people frowning
                                                and saying “well HTTP doesn’t really solve my problem so what’s
                                                the point – let’s make a new TCP-based wire protocol.”

                                                > > > One thing I dislike about AtomPub, and I know I'm probably
                                                > > > in the minority here, is it requires special tools to
                                                > > > interact with vs. just having a browser,
                                                >
                                                > > Wait, first you're telling me you don't like
                                                > > one-size-fits-all advocacy for Atompub, then you tell me we
                                                > > should just shoehorn all apps into the browser? :-)
                                                >
                                                > You are putting words in my mouth, as usual. :)
                                                >
                                                > I didn't say that I didn't like the one-size-fits-all aspect,
                                                > that aspect I do like; the uniform interface. What I was tryng
                                                > to say is there will still be a need for use-case specifics and
                                                > without some way to identify and codify those we'll end up with
                                                > the same problem, albeit higher up the stack (Is there an echo
                                                > in here? Am I repeating myself? :)

                                                No, you’re not. I see two different statements. If the latter is
                                                what you meant by the first, then the first one was not explicit
                                                enough for me to understand it clearly.

                                                Considering the latter argument, though, I’m not sure how “just
                                                having a browser” solves the problem that Atompub purportedly
                                                does not. Is it because HTML bundles the app chrome alongside the
                                                data, which Atompub does not?

                                                If so, I don’t see this as a strong objection. I assume we will
                                                see technologies other than HTML (eg. XForms) or complementary
                                                to HTML (eg. you an HTML page generated by an XSL transform
                                                referred to from an xml-stylesheet PI in the Atompub service
                                                document – assuming browsers had support for PUT and DELETE,
                                                and/or your server knew how to tunnel them through POST for
                                                legacy browser).

                                                > > Me, I hope that Atompub uptake is strong enough that we'll
                                                > > see browsers expand to support everything required that one
                                                > > day we shall, in fact, be able to interact with many Atompub
                                                > > services with just a browser.
                                                >
                                                > I have mixed feelings about that. Yes, I assume I would like
                                                > browser support but frankly I find the browser support in IE7
                                                > of RSS disconcerting.

                                                That sounds to me like “it doesn’t work the way it always used to
                                                and that freaks me out.” There are developments that weird me out
                                                too, but what they make me worry about is me, not the new ways;
                                                I don’t want to get crusty and set in my ways.

                                                See also http://www.douglasadams.com/dna/19990901-00-a.html

                                                > I strongly believe there should be only one primary format for
                                                > the web, HTML.

                                                HTML is going exactly nowhere. All of the content I consume on
                                                the web today is HTML. However most of the time it comes wrapped
                                                in something that’s not `text/html`. What I see is just the
                                                application chrome moving out of HTML and into structured formats
                                                so that the content can stand pure and undiluted. I don’t see how
                                                you can disagree that this is a good thing unless you prefer
                                                visiting 300 sites in your browser over reading them in an
                                                aggregator.

                                                > > (In fact, with XMLHttpRequest you already can.)
                                                >
                                                > Actually, that's not true. Browsers don't natively display
                                                > things using XMLHttpRequest, it is a capability that needs to
                                                > be programmed. By your logic then Java applets and in some
                                                > browsers ActiveX controls can all be interacted with via a
                                                > browser. Tell me, how many grandmas are interacting with
                                                > XMLHttpRequest?

                                                Your examples are at the extreme end of the continuum. Javascript
                                                is code run by the browser, but it’s much closer to “content” in
                                                many characteristics than are applets and ActiveX controls.

                                                Note that I consider XMLHttpRequest an interim solution only. I’m
                                                not saying it’s the way things should work; however I *am* saying
                                                that you can use to make these things *work* in the here and now.

                                                Running code trumps theoretical purity.

                                                > > > it requires web services be created in addition to web
                                                > > > pages.
                                                > > >
                                                > > > I'd really advocate for exposing webservices as a default
                                                > > > case via semantic HTML instead of AtomPub
                                                > >
                                                > > How is that different? A WordPress blog has a public face and
                                                > > an admin area. Isn't it really kind of incidental what kind
                                                > > of content types get exchanged on which half of the service?
                                                >
                                                > The differences are:
                                                >
                                                > • the requirement to develop seperately for multiple content
                                                > types.
                                                > • the high liklihood that the two efforts will result in output
                                                > lacking 100% fidelity.
                                                > • the high liklihood that the web service won't be developed
                                                > even though the web site is.
                                                > • that tools available for HTML, including browsers, will never
                                                > in their entirety be available for AtomPub.
                                                > • the fact that the default interaction for users on the web is
                                                > with content that behaves like HTML
                                                >
                                                > Having it be a best practice where building a website means
                                                > building a web service will ensure many more web services
                                                > actually get built. […] The only way it is viable in my world
                                                > view is if the CMS that is generating the content type
                                                > generates them with 100% fidelity without user/admin
                                                > involvement

                                                I think you are looking at it from the wrong angle, but Atompub
                                                is new and I guess it’s understandable that people have trouble
                                                imagining how their instincts would be changed by a world in
                                                which it was already ubiquitous.

                                                Here’s the point (again): Atompub is infrastructure.

                                                Think for a moment about a world in which plenty of ready-made
                                                implementations exist as pluggable libraries or frameworks, or
                                                maybe even fullblown servers on the scale of Apache. (OK, the
                                                latter is less likely.) In this world, no one would think of the
                                                task as “writing an Atompub implementation alongside the HTML
                                                interface.” You would use an Atompub imlpementation to build the
                                                plumbing of your application, and then write the HTML interface
                                                as a client application on top of the Atompub service. The
                                                Atompub service just falls out of that for free.

                                                > you mention that AtomPub handles things for you so you don't
                                                > have to. I've read the AtomPub spec, although I don't know how
                                                > awake I was reading it considering how long it is, and I didn't
                                                > see anything earth shattering. I see AtomPub as a very valuable
                                                > albeit specialty protocol/format. It seems you see it for
                                                > general purpose use. Can you tell me specifically what it is
                                                > about AtomPub that causes you to value its use outside the
                                                > nominal case of publishing?
                                                >
                                                > Maybe it is a panacea and I just don't yet see it. Here's your
                                                > chance, convert me.

                                                The role in which I see Atompub is retrofitting HTTP with a
                                                notion of collections. In so doing it sets up expectations for
                                                clients about how the mechanics of creating resources on the
                                                server will work.

                                                The only means for changing state on the server with a browser is
                                                HTML forms and POST. But these forms and POST requests are mute
                                                and featureless; the browser has no idea whatsoever about the
                                                meaning of what it’s doing. You need a human to drive it.

                                                With Atompub, the client is no longer just putting forth its fist
                                                with eyes shut tight, murmuring “here’s some data, I don’t know
                                                what you want it for.” It can actually have an intent for that
                                                data and a notion of what is going to happen with it.

                                                Consider Amazon S3; it’s such a simple service that if it had
                                                happened 5 years later the documentation would consist of “see
                                                RFC <whatever Atompub will be assigned>” and no one would be
                                                writing custom clients for it.

                                                But that only scratches the surface. Think about how ubiquitous
                                                the notion of collections is. To quote Bill de hÓra:

                                                <http://www.dehora.net/journal/2007/07/shipping_notes.html>:
                                                AtomPub sits in a very strange place, as it has the potential
                                                to disrupt half a dozen or more industry sectors, such as,
                                                Enterprise Content Management, Blogging, Digital/Desktop
                                                Publishing and Archiving, Mobile Web, EAI/WS-* messaging,
                                                Social Networks, Online Productivity tools. As interesting as
                                                the adoption rates, will be people and sectors finding
                                                reasons not use it to protect distribution channels and data
                                                lockins with more complicated solutions. Any kind of data
                                                garden is fair game for AtomPub to rationalize.

                                                This is much, much bigger than publishing systems.

                                                Regards,
                                                --
                                                Aristotle Pagaltzis // <http://plasmasturm.org/>
                                              • Mike Schinkel
                                                ... Sigh. I agree with your points here, but I can t seem to get you to understand mine. Maybe I m just too tired and we ll just have to leave my points for
                                                Message 23 of 23 , Aug 12, 2007
                                                • 0 Attachment
                                                  A. Pagaltzis wrote:
                                                  > No, not the *same* problem – just the *application-specific*
                                                  > part of the problem. The common parts of the problem are
                                                  > factored out to Atompub.
                                                  >
                                                  > But that’s a given; Atompub is infrastructure, just like HTTP
                                                  > itself. The fact that Atompub alone is not enough to model
                                                  > the full semantics of the application is no more to the point
                                                  > than the fact that HTTP isn’t either. Yet I don’t see people
                                                  > frowning and saying “well HTTP doesn’t really solve my
                                                  > problem so what’s the point – let’s make a new TCP-based wire
                                                  > protocol.”

                                                  Sigh. I agree with your points here, but I can't seem to get you to
                                                  understand mine. Maybe I'm just too tired and we'll just have to leave my
                                                  points for another day? :)

                                                  > (Is there an echo in here? Am I repeating myself? :)
                                                  >
                                                  > No, you’re not. I see two different statements. If the latter
                                                  > is what you meant by the first, then the first one was not
                                                  > explicit enough for me to understand it clearly.

                                                  That was a joke. Are you German?

                                                  FYI, I've got strong German heritage ("Schinkel"), so that comment was
                                                  self-depreciating as much as anything. :)

                                                  > Considering the latter argument, though, I’m not sure how
                                                  > “just having a browser” solves the problem that Atompub
                                                  > purportedly does not. Is it because HTML bundles the app
                                                  > chrome alongside the data, which Atompub does not?

                                                  One reason is that web-services-on-HTML (WSO-HTML?) can empower "happy
                                                  accidents" whereas that is unlikely for AtomPub anytime in the foreseeable
                                                  future. IOW, people surfing a combine website/web-service are more apt to
                                                  accidentally visualize how they can write web services to interact with the
                                                  site whereas most likely only people who pre-envision using web services
                                                  will be likely to move forward with building Web Services from AtomPub.

                                                  And for those who do decide to pursue web services being able to surf the
                                                  web service only requires the browser. "Surfing" an AtomPub service will
                                                  require specialized clients. The more "surfable" a web service is, the more
                                                  approachable it is IMO.

                                                  Not to mention the fact that building WSO-HTML means that only one project
                                                  is required to be approved by its sponsor (company, government agency,
                                                  department, manager, etc.) instead of two, albeit one with more constraints.

                                                  > If so, I don’t see this as a strong objection. I assume we
                                                  > will see technologies other than HTML (eg. XForms) or
                                                  > complementary to HTML (eg. you an HTML page generated by an
                                                  > XSL transform referred to from an xml-stylesheet PI in the
                                                  > Atompub service document – assuming browsers had support for
                                                  > PUT and DELETE, and/or your server knew how to tunnel them
                                                  > through POST for legacy browser).

                                                  Good. :)

                                                  > That sounds to me like “it doesn’t work the way it always
                                                  > used to and that freaks me out.” There are developments that
                                                  > weird me out too, but what they make me worry about is me,
                                                  > not the new ways; I don’t want to get crusty and set in my ways.

                                                  No, it's more like recognizing Jakob's law:
                                                  http://notebook.arkane-systems.net/index.php/Jakob's_Law_of_the_Web_User_Exp
                                                  erience

                                                  > See also http://www.douglasadams.com/dna/19990901-00-a.html

                                                  Funny, my Well Designed URLs initiative [1] is consistent with that...

                                                  > > I strongly believe there should be only one primary format for the
                                                  > > web, HTML.
                                                  >
                                                  > HTML is going exactly nowhere. All of the content I consume
                                                  > on the web today is HTML. However most of the time it comes
                                                  > wrapped in something that’s not `text/html`. What I see is
                                                  > just the application chrome moving out of HTML and into
                                                  > structured formats so that the content can stand pure and
                                                  > undiluted. I don’t see how you can disagree that this is a
                                                  > good thing unless you prefer visiting 300 sites in your
                                                  > browser over reading them in an aggregator.

                                                  I don't follow your vision for the future well enough to agree or disagree.

                                                  > Your examples are at the extreme end of the continuum.
                                                  > Javascript is code run by the browser, but it’s much closer
                                                  > to “content” in many characteristics than are applets and
                                                  > ActiveX controls.

                                                  The extreme ends are exactly what I am trying to advocate for.

                                                  And your points are simply drawing rationalizing distinctions rather than
                                                  recognize the distinction I was making regarding those thing people can
                                                  retrieve and view with a browser and those things that require other tools
                                                  and/or are hidden and require programming skill to utilize during the
                                                  browsing experience (i.e. Javascript)

                                                  > Note that I consider XMLHttpRequest an interim solution only.
                                                  > I’m not saying it’s the way things should work; however I
                                                  > *am* saying that you can use to make these things *work* in
                                                  > the here and now.

                                                  You can. I can. MOST people CANNOT.

                                                  > Running code trumps theoretical purity.

                                                  And how does that related to what we are discussing?

                                                  > I think you are looking at it from the wrong angle, but
                                                  > Atompub is new and I guess it’s understandable that people
                                                  > have trouble imagining how their instincts would be changed
                                                  > by a world in which it was already ubiquitous.

                                                  I am generally the one who tries to understand why others don't have the
                                                  vision, so it is hard for me to take that comment without feeling a tad
                                                  defensive.

                                                  There are two reasons to mention here why I think HTML is important; 1.)
                                                  Jakobs Law [1] and 2.) The "view source effect." People are much more apt
                                                  to "view source" and discover web services on HTML pages they happen to be
                                                  surfing than they are apt to view source on AtomPub resources that they
                                                  don't happen to be surfing.

                                                  Don't get me wrong. There is a great chance AdamPub will represent the
                                                  professional end of web services as you likely envision and that for those
                                                  who are serious will gravitate to AtomPub in addition to WSO-HTML. Many who
                                                  start with WSO-HTML would likely then grativate to AtomPub as they gained
                                                  success. But in my world view WSO-HTML empowers everyman to create web
                                                  services, at least read-only web services.

                                                  > Here’s the point (again): Atompub is infrastructure.

                                                  Fine. So is HTML. One should not obviate the other.

                                                  > Think for a moment about a world in which plenty of
                                                  > ready-made implementations exist as pluggable libraries or
                                                  > frameworks, or maybe even fullblown servers on the scale of
                                                  > Apache. (OK, the latter is less likely.) In this world, no
                                                  > one would think of the task as “writing an Atompub
                                                  > implementation alongside the HTML interface.” You would use
                                                  > an Atompub imlpementation to build the plumbing of your
                                                  > application, and then write the HTML interface as a client
                                                  > application on top of the Atompub service. The Atompub
                                                  > service just falls out of that for free.

                                                  Are you saying that people would build AtomPub-based websites and then apply
                                                  an HTML layer? While I agree that this might be likely in larger
                                                  enterprises or serious web business I highly doubt we'll ever see the 80% of
                                                  the bottom of the pyramid doing that because to them it is an unnecessary
                                                  level of indirection. And that 80% is the part of the pyramid that
                                                  interests me most.

                                                  > The role in which I see Atompub is retrofitting HTTP with a
                                                  > notion of collections. In so doing it sets up expectations
                                                  > for clients about how the mechanics of creating resources on
                                                  > the server will work.

                                                  Okay, I'll buy that. One of the big problems with VBScript on ASP was its
                                                  lack of usable collections.

                                                  > The only means for changing state on the server with a
                                                  > browser is HTML forms and POST. But these forms and POST
                                                  > requests are mute and featureless; the browser has no idea
                                                  > whatsoever about the meaning of what it’s doing. You need a
                                                  > human to drive it.

                                                  Accepted.

                                                  > With Atompub, the client is no longer just putting forth its
                                                  > fist with eyes shut tight, murmuring “here’s some data, I
                                                  > don’t know what you want it for.” It can actually have an
                                                  > intent for that data and a notion of what is going to happen with it.

                                                  Okay, but can you give me specific examples? "Show me the code!" :)

                                                  > Consider Amazon S3; it’s such a simple service that if it had
                                                  > happened 5 years later the documentation would consist of
                                                  > “see RFC <whatever Atompub will be assigned>” and no one
                                                  > would be writing custom clients for it.

                                                  My initiatve [2] with Alan Dean (that I haven't had time for in quite a
                                                  while but do plan to return to) has a goal of minimizing custom clients.

                                                  > But that only scratches the surface. Think about how
                                                  > ubiquitous the notion of collections is. To quote Bill de hÓra:
                                                  >
                                                  > <http://www.dehora.net/journal/2007/07/shipping_notes.html>:
                                                  > AtomPub sits in a very strange place, as it has the potential
                                                  > to disrupt half a dozen or more industry sectors, such as,
                                                  > Enterprise Content Management, Blogging, Digital/Desktop
                                                  > Publishing and Archiving, Mobile Web, EAI/WS-* messaging,
                                                  > Social Networks, Online Productivity tools. As interesting as
                                                  > the adoption rates, will be people and sectors finding
                                                  > reasons not use it to protect distribution channels and data
                                                  > lockins with more complicated solutions. Any kind of data
                                                  > garden is fair game for AtomPub to rationalize.
                                                  >
                                                  > This is much, much bigger than publishing systems.

                                                  Okay. That said, what's wrong with applying the notice of collections to
                                                  semantic HTML?

                                                  --
                                                  -Mike Schinkel
                                                  http://www.mikeschinkel.com/blogs/
                                                  http://www.welldesignedurls.org
                                                  http://atlanta-web.org - http://t.oolicio.us


                                                  [1] http://www.welldesignedurls.org
                                                  [2] http://simplewebservices.org
                                                Your message has been successfully submitted and would be delivered to recipients shortly.