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

RE: [whatwg] Proposing URI Templates for WebForms 2.0

Expand Messages
  • Mike Schinkel
    Mark; Mark I didn t see any use cases in the original e-mail; did I miss something? An example or two tends to focus discussion well... Example use-cases?
    Message 1 of 25 , Nov 1, 2008
    • 0 Attachment
      Mark;

      Mark>> I didn't see any use cases in the original e-mail; did I miss
      something? An example or two tends to focus discussion well...

      Example use-cases? You want example use-cases? Happy to oblige. :-)

      But first let me ask you think in terms of the context where people can put
      HTML put can't put Javascript such as in some hosting blogging platforms and
      on forums. Also think in terms of websites being able to say "post this code
      into your blog, etc."

      1.) I'm (hypothetically) the owner of atllogos.com and I want on provide an
      HTML for to let visitors select from a drop-down to be able to visit the
      Twitter users listed on http://atllogos.com/startup.html (Note that
      "template" is a new attribute that is used for templates when no "action" is
      specified):

      See these people on Twitter:
      <form method="get" template="http://twitter.com/{name}">
      <select id="name">
      <option>sanjay</option>
      <option>lance</option>
      <option>stephenfleming</option>
      <option>keithmcgreggor</option>
      <option>melaniebrandt</option>
      <option>jhaynie</option>
      <option>MikeSchinkel</option>
      <option>coty</option>
      <option>wei_yang</option>
      <option>mmealling</option>
      <option>pfreet</option>
      </select>
      <input type="submit" value="Go!">
      </form>

      2.) I'm writing a blog post on WordPress.com where I am advocating that
      people living in Georgia find and join a meetup group so I give them a form
      with a drop-down that allows them to select their city:

      Select your state:
      <form method="get" template="http://www.meetup.com/cities/us/ga/{city}/">
      <select id="city">
      <option value="acworth">Acworth</option>
      <option value="albany">Albany</option>
      <!-- ... -->
      <option value="warner_robins">Warner Robins</option>
      <option value="woodstock">Woodstock</option>
      </select>
      <input type="submit" value="Find a Meetup Group in Georgia!">
      </form>

      3.) I am writing a blog post on Blogger.com about "Ride to Work Day" where I
      am advocating people in the USA ride their motorcycle to work and I want to
      include a form that let's them type in their ZIP code and check there
      weather:

      <form method="get" template="http://www.weather.com/weather/local/{zip}/">
      <input type="text" name="zip"/>
      <input type="submit" value="Check Weather!">
      </form>

      And I can go on and on like this if doing so is what it will take to get URI
      Templates support in HTML5 forms. :-)

      Currently what I am doing SIMPLY CANNOT be accomplished if one doesn't have
      access to Javascript or when they don't have the programming skill.

      BTW, I'm making a strong and reasonable assumption here that the URI
      Authorities I've mentioned will each be documenting that their URL structure
      and thus blessing this approach so this DOES NOT violate URI Opacity.

      In the case of #1 and #2, spiders like Google can crawl those as well but
      could not crawl them. That's especially important if someone decides to
      architect a site using "clean" URLs and then use drop-downs in forms to
      allow people to navigate to pages. If implemented in Javascript it can't be
      reliably called but if URI templates were supported in forms it could be.

      As I told Ian in a private email recently, there are really only 3 things I
      want to HTML5 and they all related to forms:

      1.) URI Templates in forms,
      2.) PUT in forms, and
      3.) DELETE in forms. :-)

      So do my use-case examples pass your "compelling" test, or do I have to
      continue trying? :-)

      -Mike Schinkel
      President; NewClarity LLC
      Organizer: Atlanta Web Entrepreneurs
      http://www.linkedin.com/in/mikeschinkel
      http://twitter.com/mikeschinkel
      http://mikeschinkel.com
      http://atlanta-web.org


      -----Original Message-----
      From: Mark Nottingham [mailto:mnot@...]
      Sent: Saturday, November 01, 2008 1:24 AM
      To: Mike Schinkel
      Cc: 'Ian Hickson'; 'Jerome Louvel'; whatwg@...; uri@...;
      rest-discuss@yahoogroups.com
      Subject: Re: [whatwg] Proposing URI Templates for WebForms 2.0

      I didn't see any use cases in the original e-mail; did I miss something? An
      example or two tends to focus discussion well...

      Cheers,


      On 01/11/2008, at 12:59 PM, Mike Schinkel wrote:

      > Mark>> compelling use cases for this, but we haven't seen those yet
      > AFAIK.
      >
      > What classifies as a "compelling use-case" in your mind?
      >
      > -Mike Schinkel
      > President; NewClarity LLC
      > Organizer: Atlanta Web Entrepreneurs
      > http://www.linkedin.com/in/mikeschinkel
      > http://twitter.com/mikeschinkel
      > http://mikeschinkel.com
      > http://atlanta-web.org
      >
      >
      > -----Original Message-----
      > From: uri-request@... [mailto:uri-request@...] On Behalf Of Mark
      > Nottingham
      > Sent: Friday, October 31, 2008 6:38 PM
      > To: Ian Hickson
      > Cc: Jerome Louvel; whatwg@...; uri@...;
      > rest-discuss@yahoogroups.com
      > Subject: Re: [whatwg] Proposing URI Templates for WebForms 2.0
      >
      >
      > +1, although I'd say it a bit differently.
      >
      > Doing it in script precludes unintended reuse, e.g., for
      > accessibility,
      > search engines, and so forth; it's not a good solution
      > *if* there are compelling use cases for this, but we haven't seen
      > those yet
      > AFAIK.
      >
      > Cheers,
      >
      >
      > On 29/10/2008, at 6:20 AM, Ian Hickson wrote:
      >
      >>
      >> On Fri, 12 Jan 2007, Jerome Louvel wrote:
      >>>
      >>> Even though the URI template RFC is not finalized yet, we already
      >>> have a complete support for it, on the server-side, in the Restlet
      >>> framework.
      >>> We happily use them for our URI-based routing and I think they add a
      >>> lot of expressiveness while keeping a simple syntax. Usage example:
      >>> http://www.restlet.org/tutorial#part11
      >>>
      >>> They are also supported in WADL, the RESTful description language,
      >>> and in the OpenSearch specification. Extending their usage to HTML
      >>> forms sounds like a logical and useful step.
      >>
      >> It seems to me like URI templates can be trivially done from script
      >> and from the server side already; given the poor
      >> backwards-compatibility story of URI templates, what do we gain from
      >> adding it to the language?
      >>
      >> --
      >> Ian Hickson U+1047E )
      >> \._.,--....,'``. fL
      >> http://ln.hixie.ch/ U+263A /, _.. \ _
      >> \ ;`._ ,.
      >> Things that are impossible just take longer. `._.-(,_..'--
      >> (,_..'`-.;.'
      >>
      >
      >
      > --
      > Mark Nottingham http://www.mnot.net/
      >
      >


      --
      Mark Nottingham http://www.mnot.net/
    • Mike Schinkel
      Mark Nottingham This is good and I agree that in a perfect world, more flexibility would have been designed in from the start. However, to put them into the
      Message 2 of 25 , Nov 1, 2008
      • 0 Attachment
        Mark Nottingham>> This is good and I agree that in a perfect world, more
        flexibility would have been designed in from the start. However, to put them
        into the mix while the machine is running is a bit more complex; there needs
        to be something more compelling (there's that word again) to drive adoption.

        Can you help me understand the comment on why "putting them into the mix
        while the machine is running is a bit more complex?" I guess I don't
        understand either "while the machine is running" part and why it is more
        complex. What about it is more complex.

        Mark Nottingham>> If you can find cases where someone can reuse that
        template in an unintended way -- e.g., a search engine, a client doing
        automated things, a non-traditional browser, an intermediary -- I think it'd
        go a long way towards this.

        Hopefully the 3 examples I gave in my ealier email presents relevent cases?

        Mark Nottingham>> And, if you can come up with those cases, why not define
        it as an extension (since it needs to be largely backwards-compatible
        anyway)?

        What exactly is an HTML5 extension? Can you provide a link that explains
        this? I can't comment as to if it would be an acceptable substitute until I
        know more...

        Mark Nottingham>> If it takes off, you can have the satisfaction of seeing
        it incorporated into HTML6...

        Please PLEASE don't make us wait until 2032 or so for this! ;-)


        -Mike Schinkel
        President; NewClarity LLC
        Organizer: Atlanta Web Entrepreneurs
        http://www.linkedin.com/in/mikeschinkel
        http://twitter.com/mikeschinkel
        http://mikeschinkel.com
        http://atlanta-web.org
      • Paul Prescod
        ... The Mechanize family of libraries would presumably be able to take advantage of them as they do current forms. With mechanize you can ask a headless client
        Message 3 of 25 , Nov 1, 2008
        • 0 Attachment
          On Fri, Oct 31, 2008 at 10:40 PM, Mark Nottingham <mnot@...> wrote:
          I missed the second link, which does contain examples; apologies.


          If you can find cases where someone can reuse that template in an
          unintended way -- e.g., a search engine, a client doing automated
          things, a non-traditional browser, an intermediary -- I think it'd go
          a long way towards this. I can't think of any at the moment, but
          that's likely just evidence of my imagination's limits at this point
          in time.

          The Mechanize family of libraries would presumably be able to take advantage of them as they do current forms. With mechanize you can ask a headless client library to "load a page", "fill out some fields in a form" and "submit" and it infers what HTTP requests to make based on the form's structure. It cannot do this if the form is based upon Javascript. So I'd say that's a generalized argument against depending on Javascript for form capabilities, orthogonal to the question of how rich forms' URI-building capabilities need to be.

           Paul Prescod

        • Mark Nottingham
          ... Because you re not introducing your idea to a new proposal that will succeed or fail on its own merits; you re trying to get it into one of the most
          Message 4 of 25 , Nov 1, 2008
          • 0 Attachment
            On 01/11/2008, at 6:44 PM, Mike Schinkel wrote:

            > Mark Nottingham>> This is good and I agree that in a perfect world,
            > more
            > flexibility would have been designed in from the start. However, to
            > put them
            > into the mix while the machine is running is a bit more complex;
            > there needs
            > to be something more compelling (there's that word again) to drive
            > adoption.
            >
            > Can you help me understand the comment on why "putting them into the
            > mix
            > while the machine is running is a bit more complex?" I guess I don't
            > understand either "while the machine is running" part and why it is
            > more
            > complex. What about it is more complex.

            Because you're not introducing your idea to a new proposal that will
            succeed or fail on its own merits; you're trying to get it into one of
            the most widely-used formats in the world. As such, the barrier to
            entry is higher; it has to be, or every idea that seems to be good
            would get in, and HTML5 would be even more incomprehensible than it is
            now.


            > Mark Nottingham>> If you can find cases where someone can reuse that
            > template in an unintended way -- e.g., a search engine, a client doing
            > automated things, a non-traditional browser, an intermediary -- I
            > think it'd
            > go a long way towards this.
            >
            > Hopefully the 3 examples I gave in my ealier email presents relevent
            > cases?

            Sorry, but no. Each of those, as Ian says, can be implemented with a
            very simple server-side script. Yes, it's true that this requires
            somebody to write the script, but I don't think that's a big enough
            win to justify new core syntax in HTML if there isn't a constituency
            for it beating down the door.

            To be clear, I'm somewhat playing devils' advocate here; I don't have
            any particular problem per se with your proposal, it's just that I'm
            wary of putting things into standards unless we're sure we need them.
            I don't (yet) hear people beating down Ian's door to include this, so
            it makes me suspicious.

            OTOH I just saw a message from Paul P go by, so maybe this little
            dialogue will help whip up the masses.

            *ahem*


            > Mark Nottingham>> And, if you can come up with those cases, why not
            > define
            > it as an extension (since it needs to be largely backwards-compatible
            > anyway)?
            >
            > What exactly is an HTML5 extension? Can you provide a link that
            > explains
            > this? I can't comment as to if it would be an acceptable substitute
            > until I
            > know more...
            >
            > Mark Nottingham>> If it takes off, you can have the satisfaction of
            > seeing
            > it incorporated into HTML6...
            >
            > Please PLEASE don't make us wait until 2032 or so for this! ;-)


            I'm not the person to ask that, but frankly if you want the
            functionality, go ahead and write the software, publish the site,
            release the browser plug-in; the standards will follow if the minds do.

            Cheers,


            --
            Mark Nottingham http://www.mnot.net/
          • Mike Schinkel
            Mark Nottingham Sorry, but no. Each of those, as Ian says, can be implemented with a very simple server-side script. Yes, it s true that this requires
            Message 5 of 25 , Nov 1, 2008
            • 0 Attachment
              Mark Nottingham>>Sorry, but no. Each of those, as Ian says, can be
              implemented with a very simple server-side script. Yes, it's true that this
              requires somebody to write the script...

              How exact can it be implemented on the server when the person writing the
              HTML form is in control of the server? THAT's the primary use case.

              In the case of someone being in control of the server it then requires two
              round-trips and from what I know is that too many people priorize
              performance over everything else which means too many people simple won't
              implement on their servers.

              Mark Nottingham>> isn't a constituency for it beating down the door.

              Me, Jerome and Paul are a constituency. :)

              >> I don't (yet) hear people beating down Ian's door to include this, so it
              makes me suspicious.

              Do I need to start yelling louder? :-)

              Adding URI Templates to forms fills a large hole in the forms architecture;
              This is very much a case of empowering serendipity as the current form
              architecture current cannotly service the full range of URLs that can be
              used. I'm asking for (most of) that gap to be filled.

              Mark Nottingham>> I'm not the person to ask that, but frankly if you want
              the functionality, go ahead and write the software, publish the site,
              release the browser plug-in; the standards will follow if the minds do.

              That's a non-sequitur; that's like telling me to build a natural-gas powered
              car and expect that people will buy it when in fact there are not enough
              natural-gas stations available. Your suggestion that the solution is to
              write a browser plug-in is about like suggesting I just pound sand although
              it is a bit less insulting. :-)

              No one will use the syntax until enough people have the plugin, and nobody
              will install the plugin unless enough people are using the syntax; it's a
              catch-22. This type of thing is where standards are needed in advance.

              -Mike Schinkel
              http://mikeschinkel.com
            • Mark Nottingham
              *sigh* we seem to be talking past each other... despite appearances, I actually think this is a pretty good idea; I just am concerned about how you re going
              Message 6 of 25 , Nov 1, 2008
              • 0 Attachment
                *sigh* we seem to be talking past each other... despite appearances, I
                actually think this is a pretty good idea; I just am concerned about
                how you're going about getting it accepted.

                On 01/11/2008, at 8:16 PM, Mike Schinkel wrote:

                > Mark Nottingham>>Sorry, but no. Each of those, as Ian says, can be
                > implemented with a very simple server-side script. Yes, it's true
                > that this
                > requires somebody to write the script...
                >
                > How exact can it be implemented on the server when the person
                > writing the
                > HTML form is in control of the server? THAT's the primary use case.

                I suspect you meant to say when that person *isn't* in control of the
                server.

                If so, I've never been very swayed by the notion that people
                publishing on geocities (or twitter or whatever else is the free
                hosting / republishing provider of the moment is) should be able to
                make a fully-functional Web app using nothing but HTML and sticky
                tape; see previous discussions about the cross-site access control
                mechanism.


                > In the case of someone being in control of the server it then
                > requires two
                > round-trips and from what I know is that too many people priorize
                > performance over everything else which means too many people simple
                > won't
                > implement on their servers.

                Plenty of performance-sensitive sites use redirects to implement
                various functions, and they're good enough despite their two round
                trips. Perfect, no, but good enough.


                > Adding URI Templates to forms fills a large hole in the forms
                > architecture;

                Using "filling a hole in the architecture" as a justification for
                doing something gives me the screaming heebee-jeebees, and I suspect
                that this attitude is why you're getting a fairly cold shoulder from
                implementers. Show them the real market need that you're filling and I
                imagine you'll get a lot more of their attention.


                > Mark Nottingham>> I'm not the person to ask that, but frankly if you
                > want
                > the functionality, go ahead and write the software, publish the site,
                > release the browser plug-in; the standards will follow if the minds
                > do.
                >
                > That's a non-sequitur; that's like telling me to build a natural-gas
                > powered
                > car and expect that people will buy it when in fact there are not
                > enough
                > natural-gas stations available. Your suggestion that the solution is
                > to
                > write a browser plug-in is about like suggesting I just pound sand
                > although
                > it is a bit less insulting. :-)

                I wasn't suggesting a plug-in for the cases you were talking about,
                but rather in general, if you have running code and demonstrated pain,
                asking to put something into a standard is a lot more reasonable.


                > No one will use the syntax until enough people have the plugin, and
                > nobody
                > will install the plugin unless enough people are using the syntax;
                > it's a
                > catch-22. This type of thing is where standards are needed in advance.

                That is certainly how people often try to misuse standards, yes. Just
                because something is a standard doesn't make it implemented or
                successful.

                Try what I did with hinclude <http://www.mnot.net/javascript/hinclude/
                >; write a javascript library to handle a declarative syntax, and
                have it gracefully degrade once the browsers handle it natively. If
                the markup is declarative, it doesn't matter if it's in HTML5 or not,
                you still can cater to unintended uses.

                Oh, wait, I already did that: <http://www.mnot.net/javascript/template_form.js
                >.

                Sure, you don't get the leverage of having it in a mature standard,
                but if it's truly a good idea, you'll be able to convince people to
                use it without that. The point is that you can't force a good idea on
                the market with a standard; people have to want to use it. I've said
                about as much as I can about this without starting to babble about
                standards theory, so I think I'll stop now.

                --
                Mark Nottingham http://www.mnot.net/
              • Julian Reschke
                ... Speaking of which: that one (hinclude) is totally useful; and it would also help with one of the cases Google s recent dictionary-based compression
                Message 7 of 25 , Nov 1, 2008
                • 0 Attachment
                  Mark Nottingham wrote:
                  > ...
                  > Try what I did with hinclude <http://www.mnot.net/javascript/hinclude/>;
                  > write a javascript library to handle a declarative syntax, and have it
                  > gracefully degrade once the browsers handle it natively. If the markup
                  > is declarative, it doesn't matter if it's in HTML5 or not, you still can
                  > cater to unintended uses.
                  > ...

                  Speaking of which: that one (hinclude) is totally useful; and it would
                  also help with one of the cases Google's recent dictionary-based
                  compression proposal is for.

                  I'd totally be in favor to have something like this in HTML5 (and no,
                  others have asked for it as well).

                  BR, Julian
                • Mike Schinkel
                  Mark Nottingham despite appearances, I actually think this is a pretty good idea; I just am concerned about how you re going about getting it accepted. I can
                  Message 8 of 25 , Nov 1, 2008
                  • 0 Attachment
                    Mark Nottingham>>despite appearances, I actually think this is a pretty good
                    idea; I just am concerned about how you're going about getting it accepted.

                    I can understand, appreciate and respect that. FYI I lost patience with the
                    standard process a while back because it seemed that no matter my input I
                    was always told "no." Since I only found frustration, I gave up.

                    I'm participating again because Ian included me on a follow email on this
                    issue and because I really do want to see URI Templates become part of
                    HTML5. That said, I really have no idea how to go about getting things
                    accepted I think because I look for what could be and it seems most
                    standards people only want to see what already is?

                    If it takes untold hours of time to debate and to provide exhaustive
                    supporting evidence I guess I'll have to give up on the hope for this since
                    I really do need to use my time to make a living and no one is paying me for
                    my time to participate here.

                    If you can guide me as to how to efficently get something accepted, I'm all
                    ears!

                    >> I suspect you meant to say when that person *isn't* in control of the
                    server.

                    Yes, thanks for catching my error.

                    >> If so, I've never been very swayed by the notion that people publishing
                    on geocities (or twitter or whatever else is the free hosting / republishing
                    provider of the moment is) should be able to make a fully-functional Web app
                    using nothing but HTML and sticky tape; see previous discussions about the
                    cross-site access control mechanism.

                    First, not asking for a fully-functional web app, just for the ability to
                    incorporate usable forms into an HTML fragment where Javascript is not
                    allowed.

                    Second, hasn't it been obvious with the explosion of social media that over
                    time the vast majority of content published on the web will be published by
                    people using a server they do not control? Forums, Blog hosting, Facebook,
                    LinkedIn, etc. etc. etc.

                    Frankly it was over the lack of appreciation for social media's use of HTML
                    that I gave up on participating in the HTML5 WG. My guess is that within ten
                    years >90% of HTML on the web will be published on social media services
                    (including self hosted open-source apps) yet the participants in the HTML5
                    WG seemed to only consider HTML published by people in control of the server
                    (i.e. my "<10%") were the only valid users.

                    Honestly, there really should be a focus on making sure the HTML can work in
                    "fragment-mode" (i.e. where someone provides a fragment of HTML that is
                    incorporated within other HTML.) That calls the question of the need for a
                    <fragment> element that can contain malformed HTML w/o breaking the
                    containing HTML, but that's another subject...

                    BTW, don't you think the geocities reference is a bit of a low blow? ;)

                    >> Plenty of performance-sensitive sites use redirects to implement various
                    functions, and they're good enough despite their two round trips. Perfect,
                    no, but good enough.

                    Plenty do but more do not, and many people on forums, blog posts and mailing
                    lists recommend to others not to do so because of the performance cost. The
                    cost of round trips has been used as a reason against certain web
                    architectures such as in discussions of ROBOTS.TXT and 303.

                    Most notably people who write about web performance optimization who happen
                    to work for your employer recommend against doing so:

                    http://developer.yahoo.com/performance/rules.html#redirects
                    http://developer.yahoo.com/performance/rules.html#num_http


                    >>Using "filling a hole in the architecture" as a justification for doing
                    something gives me the screaming heebee-jeebees, and I suspect that this
                    attitude is why you're getting a fairly cold shoulder from implementers.
                    Show them the real market need that you're filling and I imagine you'll get
                    a lot more of their attention.

                    "heebee-jeebees?" Srsly?

                    I've been trying to, but you are dismissing my needs as unimportant. I
                    really don't know how to put it in terms that you guys appreciate.

                    >> I wasn't suggesting a plug-in for the cases you were talking about, but
                    rather in general, if you have running code and demonstrated pain, asking to
                    put something into a standard is a lot more reasonable.

                    What about the case where I don't have running code because we can't
                    currently do it? I am trying to empower uses where people simply can't do
                    things right now.

                    The irony is that if TBL had gotten this kind of resistance when he tried to
                    launch the web it never would have happened because he couldn't demonstrate
                    an existing use-case (Oh wait a minute, he DID get this kind of resistance
                    from the IETF, and it almost killed the web stillborne. Thank god it
                    didn't.)

                    BTW, the only person I've gotten resistance from on this besides Hixie is
                    you... :)

                    >> That is certainly how people often try to misuse standards, yes. Just
                    because something is a standard doesn't make it implemented or successful.

                    Oh I agree with that, not that it is relevant here...

                    >> Try what I did with hinclude...
                    >> Oh, wait, I already did that...
                    >> Sure, you don't get the leverage...

                    Typically when I advocate for things like this it is rarely because I want
                    it for something I need to implement, it's because I believe that it could
                    improve things on a broad scale. Frequently people will say "But you can
                    implement it yourself by doing 'x'" which totally misses the point.

                    But that misses the point; the most compelling use-cases are for where
                    Javascript isn't available!

                    >> The point is that you can't force a good idea on the market with a
                    standard; people have to want to use it.

                    I'll agree with you completely there about not implementing something people
                    wouldn't use.

                    What I'm having trouble with is that the benefits to using this are so
                    obvious to me that I'm having trouble understanding why they are not obvious
                    to others. Using a templated URL structure vs query parameters makes URLs so
                    much cleaner looking and understandable that I can't imagine people wouldn't
                    flock to using this, if available.

                    So would it help if I could show you numerous examples where people are
                    using Javascript to accomplish this with forms? Would that be the "pain" you
                    are looking for?

                    That said, what about the pain of not being able to crawl forms that use
                    Javascript for this? Isn't that a compelling use case?

                    >> I've said about as much as I can about this without starting to babble
                    about standards theory, so I think I'll stop now.

                    As an aside, I'd be interested in any reference you have that I can read up
                    on "standard's theory."

                    -Mike Schinkel
                    http://mikeschinkel.com


                    -----Original Message-----
                    From: Mark Nottingham [mailto:mnot@...]
                    Sent: Saturday, November 01, 2008 5:51 AM
                    To: Mike Schinkel
                    Cc: 'Ian Hickson'; 'Jerome Louvel'; whatwg@...; 'URI'; 'REST
                    Discuss'
                    Subject: Re: [whatwg] Proposing URI Templates for WebForms 2.0

                    *sigh* we seem to be talking past each other... despite appearances, I
                    actually think this is a pretty good idea; I just am concerned about how
                    you're going about getting it accepted.

                    On 01/11/2008, at 8:16 PM, Mike Schinkel wrote:

                    > Mark Nottingham>>Sorry, but no. Each of those, as Ian says, can be
                    > implemented with a very simple server-side script. Yes, it's true that
                    > this requires somebody to write the script...
                    >
                    > How exact can it be implemented on the server when the person writing
                    > the HTML form is in control of the server? THAT's the primary use
                    > case.

                    I suspect you meant to say when that person *isn't* in control of the
                    server.

                    If so, I've never been very swayed by the notion that people publishing on
                    geocities (or twitter or whatever else is the free hosting / republishing
                    provider of the moment is) should be able to make a fully-functional Web app
                    using nothing but HTML and sticky tape; see previous discussions about the
                    cross-site access control mechanism.


                    > In the case of someone being in control of the server it then requires
                    > two round-trips and from what I know is that too many people priorize
                    > performance over everything else which means too many people simple
                    > won't implement on their servers.

                    Plenty of performance-sensitive sites use redirects to implement various
                    functions, and they're good enough despite their two round trips. Perfect,
                    no, but good enough.


                    > Adding URI Templates to forms fills a large hole in the forms
                    > architecture;

                    Using "filling a hole in the architecture" as a justification for doing
                    something gives me the screaming heebee-jeebees, and I suspect that this
                    attitude is why you're getting a fairly cold shoulder from implementers.
                    Show them the real market need that you're filling and I imagine you'll get
                    a lot more of their attention.


                    > Mark Nottingham>> I'm not the person to ask that, but frankly if you
                    > want the functionality, go ahead and write the software, publish the
                    > site, release the browser plug-in; the standards will follow if the
                    > minds do.
                    >
                    > That's a non-sequitur; that's like telling me to build a natural-gas
                    > powered car and expect that people will buy it when in fact there are
                    > not enough natural-gas stations available. Your suggestion that the
                    > solution is to write a browser plug-in is about like suggesting I just
                    > pound sand although it is a bit less insulting. :-)

                    I wasn't suggesting a plug-in for the cases you were talking about, but
                    rather in general, if you have running code and demonstrated pain, asking to
                    put something into a standard is a lot more reasonable.


                    > No one will use the syntax until enough people have the plugin, and
                    > nobody will install the plugin unless enough people are using the
                    > syntax; it's a catch-22. This type of thing is where standards are
                    > needed in advance.

                    That is certainly how people often try to misuse standards, yes. Just
                    because something is a standard doesn't make it implemented or successful.

                    Try what I did with hinclude <http://www.mnot.net/javascript/hinclude/
                    >; write a javascript library to handle a declarative syntax, and have it
                    gracefully degrade once the browsers handle it natively. If the markup is
                    declarative, it doesn't matter if it's in HTML5 or not, you still can cater
                    to unintended uses.

                    Oh, wait, I already did that:
                    <http://www.mnot.net/javascript/template_form.js
                    >.

                    Sure, you don't get the leverage of having it in a mature standard, but if
                    it's truly a good idea, you'll be able to convince people to use it without
                    that. The point is that you can't force a good idea on the market with a
                    standard; people have to want to use it. I've said about as much as I can
                    about this without starting to babble about standards theory, so I think
                    I'll stop now.

                    --
                    Mark Nottingham http://www.mnot.net/
                  • Mark Nottingham
                    ... Yes, but consider how little HTML is allowed by most of these, and why... ... Of course; the point I was trying to make is that avoiding a roundtrip isn t
                    Message 9 of 25 , Nov 1, 2008
                    • 0 Attachment
                      On 01/11/2008, at 9:44 PM, Mike Schinkel wrote:

                      > Second, hasn't it been obvious with the explosion of social media
                      > that over
                      > time the vast majority of content published on the web will be
                      > published by
                      > people using a server they do not control? Forums, Blog hosting,
                      > Facebook,
                      > LinkedIn, etc. etc. etc.

                      Yes, but consider how little HTML is allowed by most of these, and
                      why...

                      > Plenty do but more do not, and many people on forums, blog posts and
                      > mailing
                      > lists recommend to others not to do so because of the performance
                      > cost. The
                      > cost of round trips has been used as a reason against certain web
                      > architectures such as in discussions of ROBOTS.TXT and 303.
                      >
                      > Most notably people who write about web performance optimization who
                      > happen
                      > to work for your employer recommend against doing so:
                      >
                      > http://developer.yahoo.com/performance/rules.html#redirects
                      > http://developer.yahoo.com/performance/rules.html#num_http

                      Of course; the point I was trying to make is that avoiding a roundtrip
                      isn't going to motivate a whole new technology, at least one that's so
                      specialised.

                      > BTW, the only person I've gotten resistance from on this besides
                      > Hixie is
                      > you... :)

                      True, and if you're in a position to get your proposal accepted and
                      implemented, I'll be the last to get in your way.

                      > But that misses the point; the most compelling use-cases are for where
                      > Javascript isn't available!

                      If you define it as declarative markup and implement it for the
                      browsing case with JavaScript, non-JS clients (e.g., robots) can still
                      use the declarative markup, if they're aware of it.

                      > So would it help if I could show you numerous examples where people
                      > are
                      > using Javascript to accomplish this with forms? Would that be the
                      > "pain" you
                      > are looking for?
                      >
                      > That said, what about the pain of not being able to crawl forms that
                      > use
                      > Javascript for this? Isn't that a compelling use case?

                      I think I'll stop typing and listen to what others have to say.

                      > As an aside, I'd be interested in any reference you have that I can
                      > read up
                      > on "standard's theory."


                      Carl Cargill did a good job in "Open Systems Standardization":
                      http://www.amazon.com/Open-Systems-Standardization-Business-Approach/dp/0132683199/

                      Cheers (and good night),

                      --
                      Mark Nottingham http://www.mnot.net/
                    • Mike Schinkel
                      Mark Nottingham Of course; the point I was trying to make is that avoiding a roundtrip isn t going to motivate a whole new technology, at least one that s so
                      Message 10 of 25 , Nov 1, 2008
                      • 0 Attachment
                        Mark Nottingham>> Of course; the point I was trying to make is that avoiding
                        a roundtrip isn't going to motivate a whole new technology, at least one
                        that's so specialised.

                        It really doesn't seem to be that specialized to me. URLs are used
                        ubiquitously, and a widespread implementation of URI Templates such as in
                        HTML5 could empower the use of URI Templates in so many different contexts
                        where they would have value.

                        As an aside, I'm beginning to understand that the people who get their
                        concerns addressed in the WG are the ones with the most stamina. :)

                        >> If you define it as declarative markup and implement it for the browsing
                        case with JavaScript, non-JS clients (e.g., robots) can still use the
                        declarative markup, if they're aware of it.

                        True, but the point is that nobody is going to code something when the
                        number of those aware of it are <1% given that w/o Javascript it isn't
                        possible to do it any other way.

                        >> Carl Cargill did a good job in "Open Systems Standardization":

                        Very cool, it's on order. Thanks.

                        -Mike
                      • Subbu Allamaraju
                        I see the use cases, but what is the server gaining with this flexibility? In other words, how many servers out there are going to benefit from this technique?
                        Message 11 of 25 , Nov 1, 2008
                        • 0 Attachment
                          I see the use cases, but what is the server gaining with this
                          flexibility? In other words, how many servers out there are going to
                          benefit from this technique?

                          Not having templates in forms does not violate URI opacity since HTML
                          forms do follow a well-defined and well-understood approach to
                          construct a URI from form parameters.

                          Subbu

                          On Nov 1, 2008, at 12:24 AM, Mike Schinkel wrote:

                          > Mark;
                          >
                          > Mark>> I didn't see any use cases in the original e-mail; did I miss
                          > something? An example or two tends to focus discussion well...
                          >
                          > Example use-cases? You want example use-cases? Happy to oblige. :-)
                          >
                          > But first let me ask you think in terms of the context where people
                          > can put
                          > HTML put can't put Javascript such as in some hosting blogging
                          > platforms and
                          > on forums. Also think in terms of websites being able to say "post
                          > this code
                          > into your blog, etc."
                          >
                          > 1.) I'm (hypothetically) the owner of atllogos.com and I want on
                          > provide an
                          > HTML for to let visitors select from a drop-down to be able to visit
                          > the
                          > Twitter users listed on http://atllogos.com/startup.html (Note that
                          > "template" is a new attribute that is used for templates when no
                          > "action" is
                          > specified):
                          >
                          > See these people on Twitter:
                          > <form method="get" template="http://twitter.com/{name}">
                          > <select id="name">
                          > <option>sanjay</option>
                          > <option>lance</option>
                          > <option>stephenfleming</option>
                          > <option>keithmcgreggor</option>
                          > <option>melaniebrandt</option>
                          > <option>jhaynie</option>
                          > <option>MikeSchinkel</option>
                          > <option>coty</option>
                          > <option>wei_yang</option>
                          > <option>mmealling</option>
                          > <option>pfreet</option>
                          > </select>
                          > <input type="submit" value="Go!">
                          > </form>
                          >
                          > 2.) I'm writing a blog post on WordPress.com where I am advocating
                          > that
                          > people living in Georgia find and join a meetup group so I give them
                          > a form
                          > with a drop-down that allows them to select their city:
                          >
                          > Select your state:
                          > <form method="get" template="http://www.meetup.com/cities/us/ga/
                          > {city}/">
                          > <select id="city">
                          > <option value="acworth">Acworth</option>
                          > <option value="albany">Albany</option>
                          > <!-- ... -->
                          > <option value="warner_robins">Warner Robins</option>
                          > <option value="woodstock">Woodstock</option>
                          > </select>
                          > <input type="submit" value="Find a Meetup Group in Georgia!">
                          > </form>
                          >
                          > 3.) I am writing a blog post on Blogger.com about "Ride to Work Day"
                          > where I
                          > am advocating people in the USA ride their motorcycle to work and I
                          > want to
                          > include a form that let's them type in their ZIP code and check there
                          > weather:
                          >
                          > <form method="get" template="http://www.weather.com/weather/local/
                          > {zip}/">
                          > <input type="text" name="zip"/>
                          > <input type="submit" value="Check Weather!">
                          > </form>
                          >
                          > And I can go on and on like this if doing so is what it will take to
                          > get URI
                          > Templates support in HTML5 forms. :-)
                          >
                          > Currently what I am doing SIMPLY CANNOT be accomplished if one
                          > doesn't have
                          > access to Javascript or when they don't have the programming skill.
                          >
                          > BTW, I'm making a strong and reasonable assumption here that the URI
                          > Authorities I've mentioned will each be documenting that their URL
                          > structure
                          > and thus blessing this approach so this DOES NOT violate URI Opacity.
                          >
                          > In the case of #1 and #2, spiders like Google can crawl those as
                          > well but
                          > could not crawl them. That's especially important if someone decides
                          > to
                          > architect a site using "clean" URLs and then use drop-downs in forms
                          > to
                          > allow people to navigate to pages. If implemented in Javascript it
                          > can't be
                          > reliably called but if URI templates were supported in forms it
                          > could be.
                          >
                          > As I told Ian in a private email recently, there are really only 3
                          > things I
                          > want to HTML5 and they all related to forms:
                          >
                          > 1.) URI Templates in forms,
                          > 2.) PUT in forms, and
                          > 3.) DELETE in forms. :-)
                          >
                          > So do my use-case examples pass your "compelling" test, or do I have
                          > to
                          > continue trying? :-)
                          >
                          > -Mike Schinkel
                          > President; NewClarity LLC
                          > Organizer: Atlanta Web Entrepreneurs
                          > http://www.linkedin.com/in/mikeschinkel
                          > http://twitter.com/mikeschinkel
                          > http://mikeschinkel.com
                          > http://atlanta-web.org
                          >
                          > -----Original Message-----
                          > From: Mark Nottingham [mailto:mnot@...]
                          > Sent: Saturday, November 01, 2008 1:24 AM
                          > To: Mike Schinkel
                          > Cc: 'Ian Hickson'; 'Jerome Louvel'; whatwg@...; uri@...
                          > ;
                          > rest-discuss@yahoogroups.com
                          > Subject: Re: [whatwg] Proposing URI Templates for WebForms 2.0
                          >
                          > I didn't see any use cases in the original e-mail; did I miss
                          > something? An
                          > example or two tends to focus discussion well...
                          >
                          > Cheers,
                          >
                          > On 01/11/2008, at 12:59 PM, Mike Schinkel wrote:
                          >
                          > > Mark>> compelling use cases for this, but we haven't seen those yet
                          > > AFAIK.
                          > >
                          > > What classifies as a "compelling use-case" in your mind?
                          > >
                          > > -Mike Schinkel
                          > > President; NewClarity LLC
                          > > Organizer: Atlanta Web Entrepreneurs
                          > > http://www.linkedin.com/in/mikeschinkel
                          > > http://twitter.com/mikeschinkel
                          > > http://mikeschinkel.com
                          > > http://atlanta-web.org
                          > >
                          > >
                          > > -----Original Message-----
                          > > From: uri-request@... [mailto:uri-request@...] On Behalf Of
                          > Mark
                          > > Nottingham
                          > > Sent: Friday, October 31, 2008 6:38 PM
                          > > To: Ian Hickson
                          > > Cc: Jerome Louvel; whatwg@...; uri@...;
                          > > rest-discuss@yahoogroups.com
                          > > Subject: Re: [whatwg] Proposing URI Templates for WebForms 2.0
                          > >
                          > >
                          > > +1, although I'd say it a bit differently.
                          > >
                          > > Doing it in script precludes unintended reuse, e.g., for
                          > > accessibility,
                          > > search engines, and so forth; it's not a good solution
                          > > *if* there are compelling use cases for this, but we haven't seen
                          > > those yet
                          > > AFAIK.
                          > >
                          > > Cheers,
                          > >
                          > >
                          > > On 29/10/2008, at 6:20 AM, Ian Hickson wrote:
                          > >
                          > >>
                          > >> On Fri, 12 Jan 2007, Jerome Louvel wrote:
                          > >>>
                          > >>> Even though the URI template RFC is not finalized yet, we already
                          > >>> have a complete support for it, on the server-side, in the Restlet
                          > >>> framework.
                          > >>> We happily use them for our URI-based routing and I think they
                          > add a
                          > >>> lot of expressiveness while keeping a simple syntax. Usage
                          > example:
                          > >>> http://www.restlet.org/tutorial#part11
                          > >>>
                          > >>> They are also supported in WADL, the RESTful description language,
                          > >>> and in the OpenSearch specification. Extending their usage to HTML
                          > >>> forms sounds like a logical and useful step.
                          > >>
                          > >> It seems to me like URI templates can be trivially done from script
                          > >> and from the server side already; given the poor
                          > >> backwards-compatibility story of URI templates, what do we gain
                          > from
                          > >> adding it to the language?
                          > >>
                          > >> --
                          > >> Ian Hickson U+1047E )
                          > >> \._.,--....,'``. fL
                          > >> http://ln.hixie.ch/ U+263A /, _.. \ _
                          > >> \ ;`._ ,.
                          > >> Things that are impossible just take longer. `._.-(,_..'--
                          > >> (,_..'`-.;.'
                          > >>
                          > >
                          > >
                          > > --
                          > > Mark Nottingham http://www.mnot.net/
                          > >
                          > >
                          >
                          > --
                          > Mark Nottingham http://www.mnot.net/
                          >
                          >
                          >
                        • Subbu Allamaraju
                          ... I don t disagree, and I do see the value of templates for non-browser scenarios. But the most of the web today won t be taking advantage of this for a long
                          Message 12 of 25 , Nov 1, 2008
                          • 0 Attachment
                            On Nov 1, 2008, at 10:01 AM, Erik Wilde wrote:

                            > Subbu Allamaraju wrote:
                            >> I see the use cases, but what is the server gaining with this
                            >> flexibility? In other words, how many servers out there are going
                            >> to benefit from this technique?
                            >
                            > the question is more how many page authors will be able to reliably
                            > develop forms against services/servers? i think mike's idea is
                            > pretty good because it increases loose coupling between clients and
                            > servers.

                            I don't disagree, and I do see the value of templates for non-browser
                            scenarios. But the most of the web today won't be taking advantage of
                            this for a long time.

                            > on today's web, forms and services are more or less tightly coupled,
                            > and they almost are developed as one thing. mike proposes an
                            > architecture that introduces a more loose coupling, because a form
                            > is able to interact with more services than before.

                            Again, I don't disagree about loose-coupling, but the technique serves
                            just a tiny tiny fraction. Also consider the amount of JS code out
                            there that knows how to construct URIs from form params and other
                            inputs. That won't be migrating to use templates anytime soon.

                            > ( mike, please correct me if i am wrong. )
                            >
                            >> Not having templates in forms does not violate URI opacity since
                            >> HTML forms do follow a well-defined and well-understood approach to
                            >> construct a URI from form parameters.
                            >
                            > yes, but if you have some service out there that expect certain
                            > URIs, then currently it is not possible to build a form for that,
                            > unless the service does expect form-encoded data. mike's proposal
                            > would allow forms to interact with a much wider set of services.

                            Same as above. Those services/servers can very well allow form-encoded
                            data. I would argue that, doing so is better since it would let them
                            work with existing browsers and JS libraries.

                            Sincerely,
                            Subbu
                            ----
                            http://www.subbu.org
                          • Mike Schinkel
                            Erik Wilde ( mike, please correct me if i am wrong. ) You are right, thanks. You explained it in a way that hadn t occurred to me to explain it; loose
                            Message 13 of 25 , Nov 1, 2008
                            • 0 Attachment
                              Erik Wilde>> ( mike, please correct me if i am wrong. )

                              You are right, thanks. You explained it in a way that hadn't occurred to me
                              to explain it; loose coupling is very good.

                              -Mike Schinkel
                              http://mikeschinkel.com


                              -----Original Message-----
                              From: Erik Wilde [mailto:dret@...]
                              Sent: Saturday, November 01, 2008 1:01 PM
                              To: Subbu Allamaraju
                              Cc: Mike Schinkel; 'Mark Nottingham'; 'Ian Hickson'; 'Jerome Louvel';
                              whatwg@...; uri@...; rest-discuss@yahoogroups.com
                              Subject: Re: [rest-discuss] RE: [whatwg] Proposing URI Templates for
                              WebForms 2.0

                              Subbu Allamaraju wrote:
                              > I see the use cases, but what is the server gaining with this
                              > flexibility? In other words, how many servers out there are going to
                              > benefit from this technique?

                              the question is more how many page authors will be able to reliably develop
                              forms against services/servers? i think mike's idea is pretty good because
                              it increases loose coupling between clients and servers.

                              on today's web, forms and services are more or less tightly coupled, and
                              they almost are developed as one thing. mike proposes an architecture that
                              introduces a more loose coupling, because a form is able to interact with
                              more services than before.

                              ( mike, please correct me if i am wrong. )

                              > Not having templates in forms does not violate URI opacity since HTML
                              > forms do follow a well-defined and well-understood approach to
                              > construct a URI from form parameters.

                              yes, but if you have some service out there that expect certain URIs, then
                              currently it is not possible to build a form for that, unless the service
                              does expect form-encoded data. mike's proposal would allow forms to interact
                              with a much wider set of services.

                              cheers,

                              dret.
                            • Mike Schinkel
                              Subbu I don t disagree, and I do see the value of templates for non-browser scenarios. But the most of the web today won t be taking advantage of this for a
                              Message 14 of 25 , Nov 1, 2008
                              • 0 Attachment
                                Subbu>> I don't disagree, and I do see the value of templates for
                                non-browser scenarios. But the most of the web today won't be taking
                                advantage of this for a long time.

                                HTML5 won't be taken advantage of for a very long time, so how is this a
                                critcism?

                                >> Again, I don't disagree about loose-coupling, but the technique serves
                                just a tiny tiny fraction. Also consider the amount of JS code out there
                                that knows how to construct URIs from form params and other inputs. That
                                won't be migrating to use templates anytime soon.

                                If URI Templates are added I can see them be immediately incorporated into
                                CMS like Drupal, WordPress and Joomla (I use the former two so I'll add it
                                if nobody else does) and frameworks like Ruby on Rails, Django, and CakePHP.
                                Most (all?) of those frameworks use clean URLs but can't use forms w/o using
                                Javascript and URI templates would be a cleaner and simplier approach that
                                it would be crazy for people NOT to use it.

                                I for one will blog about it and promote if via Twitter and expect others
                                like dret and Jerome (and probably Mark) will do the same.

                                >> Same as above. Those services/servers can very well allow form-encoded
                                data. I would argue that, doing so is better since it would let them work
                                with existing browsers and JS libraries.

                                So your only argument against is someone would need to create a URI Template
                                library and then they would need to use it? Just how hard is it to find and
                                use another library?

                                With that argument there should be no planning for HTML5 because "existing
                                libraries" don't work with HTML5, right?

                                @dret>> i think the main question is whether HTML should look beyond
                                services designed specifically for backing forms, or not. it certainly could
                                without harming backwards-compatibility, and one could also argue that this
                                would actually promote the design and implementation of services with more
                                well-designed RESTful APIs than form-encoded data. seen this way, such a
                                feature would be a pretty smart way of slowly improving the state of how
                                services are provided on the web.

                                Well said.

                                -Mike Schinkel
                                http://mikeschinkel.com


                                -----Original Message-----
                                From: Subbu Allamaraju [mailto:subbu@...]
                                Sent: Saturday, November 01, 2008 1:56 PM
                                To: Erik Wilde
                                Cc: Mike Schinkel; 'Mark Nottingham'; 'Ian Hickson'; 'Jerome Louvel';
                                whatwg@...; uri@...; rest-discuss@yahoogroups.com
                                Subject: Re: [rest-discuss] RE: [whatwg] Proposing URI Templates for
                                WebForms 2.0


                                On Nov 1, 2008, at 10:01 AM, Erik Wilde wrote:

                                > Subbu Allamaraju wrote:
                                >> I see the use cases, but what is the server gaining with this
                                >> flexibility? In other words, how many servers out there are going to
                                >> benefit from this technique?
                                >
                                > the question is more how many page authors will be able to reliably
                                > develop forms against services/servers? i think mike's idea is pretty
                                > good because it increases loose coupling between clients and servers.

                                I don't disagree, and I do see the value of templates for non-browser
                                scenarios. But the most of the web today won't be taking advantage of this
                                for a long time.

                                > on today's web, forms and services are more or less tightly coupled,
                                > and they almost are developed as one thing. mike proposes an
                                > architecture that introduces a more loose coupling, because a form is
                                > able to interact with more services than before.

                                Again, I don't disagree about loose-coupling, but the technique serves just
                                a tiny tiny fraction. Also consider the amount of JS code out there that
                                knows how to construct URIs from form params and other inputs. That won't be
                                migrating to use templates anytime soon.

                                > ( mike, please correct me if i am wrong. )
                                >
                                >> Not having templates in forms does not violate URI opacity since HTML
                                >> forms do follow a well-defined and well-understood approach to
                                >> construct a URI from form parameters.
                                >
                                > yes, but if you have some service out there that expect certain URIs,
                                > then currently it is not possible to build a form for that, unless the
                                > service does expect form-encoded data. mike's proposal would allow
                                > forms to interact with a much wider set of services.

                                Same as above. Those services/servers can very well allow form-encoded data.
                                I would argue that, doing so is better since it would let them work with
                                existing browsers and JS libraries.

                                Sincerely,
                                Subbu
                                ----
                                http://www.subbu.org
                              • Subbu Allamaraju
                                ... Not sure how you came to that conclusion, but I find that argument a stretch. If I understand correctly, Mike s argument for supporting templates is to
                                Message 15 of 25 , Nov 4, 2008
                                • 0 Attachment
                                  On Nov 1, 2008, at 11:38 AM, Erik Wilde wrote:

                                  > that is a circular argument. and in many cases, if you are building
                                  > a RESTful service primarily intended as an API, then URI design for
                                  > it will look very different from form-encoded data.
                                  >
                                  > i think the main question is whether HTML should look beyond
                                  > services designed specifically for backing forms, or not. it
                                  > certainly could without harming backwards-compatibility, and one
                                  > could also argue that this would actually promote the design and
                                  > implementation of services with more well-designed RESTful APIs than
                                  > form-encoded data. seen this way, such a feature would be a pretty
                                  > smart way of slowly improving the state of how services are provided
                                  > on the web.


                                  Not sure how you came to that conclusion, but I find that argument a
                                  stretch.

                                  If I understand correctly, Mike's argument for supporting templates is
                                  to avoid requiring JS support. So, a RESTful server that needs to be
                                  consumed by a browser without requiring JS support has just one option
                                  - that is to use a media type that can be recognized by browsers,
                                  which is HTML. That is, it uses (X)HTML representations, supports
                                  query parameters and forms. The so-called API server therefore becomes
                                  a web server.

                                  I can understand the merits of URI template support for HTML on its
                                  own, but I don't think it is correct to argue that such a support will
                                  make it easy to consume APIs.

                                  Sincerely,
                                  Subbu
                                  ---
                                  http://subbu.org
                                • Mike Schinkel
                                  ... ...i don t think we should make that distinction of servers; on the contrary, i think the web should take every step possible into a direction where that
                                  Message 16 of 25 , Nov 4, 2008
                                  • 0 Attachment
                                    >> Erik Wilde wrote:
                                    ...i don't think we should make that distinction of servers; on the
                                    contrary, i think the web should take every step possible into a direction
                                    where that perceived difference between "API servers" and "web servers"
                                    disappears, and where technologies that somehow create that distinction
                                    (such as HTML forms) are fixed (with reasonable transition strategies in
                                    place).

                                    Well said; I concur with this analysis and this goal completely. Adding URI
                                    Template support to HTML forms reduces the disparity between what can be
                                    done with a "website" and what must be done with an "RESTful API server" per
                                    se.

                                    There ideally should be as little technical difference between the two where
                                    the client is given the option to view it as it may. Without URI Template
                                    support HTML forms will continue to be 2nd class citizen when compared to
                                    other solutions for interacting with REST-based web services.

                                    While this hadn't been part of my original reason for request URI Template
                                    support in HTML forms it's now clear it is probably a more important
                                    justification than my original. Thanks Erik.

                                    -Mike Schinkel
                                    http://mikeschinkel.com
                                  • Subbu Allamaraju
                                    Eric and Mike, I am not convinced that URI templates will reduce that disparity. The point I was trying to make yesterday was that, when these servers become
                                    Message 17 of 25 , Nov 5, 2008
                                    • 0 Attachment
                                      Eric and Mike,

                                      I am not convinced that URI templates will reduce that disparity. The
                                      point I was trying to make yesterday was that, when these servers
                                      become the same, the server will be using a media type like HTML, and
                                      hence will have to follow the same techniques that HTML clients follow
                                      *today*. So, IMHO, the argument for templates should be discussed on
                                      its own merits for HTML.

                                      Subbu

                                      On Nov 4, 2008, at 11:45 PM, Mike Schinkel wrote:

                                      > Well said; I concur with this analysis and this goal completely.
                                      > Adding URI
                                      > Template support to HTML forms reduces the disparity between what
                                      > can be
                                      > done with a "website" and what must be done with an "RESTful API
                                      > server" per
                                      > se.
                                      >
                                      > There ideally should be as little technical difference between the
                                      > two where
                                      > the client is given the option to view it as it may. Without URI
                                      > Template
                                      > support HTML forms will continue to be 2nd class citizen when
                                      > compared to
                                      > other solutions for interacting with REST-based web services.
                                      >
                                      > While this hadn't been part of my original reason for request URI
                                      > Template
                                      > support in HTML forms it's now clear it is probably a more important
                                      > justification than my original. Thanks Erik.

                                      ---
                                      http://subbu.org
                                    • Mike Schinkel
                                      ... follow the same techniques that HTML clients follow *today*. I must be missing something but I don t see how that s a problem. Why can t HTML be used for a
                                      Message 18 of 25 , Nov 5, 2008
                                      • 0 Attachment
                                        Subbu Allamaraju wrote:
                                        >> the server will be using a media type like HTML, and hence will have to
                                        follow the same techniques that HTML clients follow *today*.

                                        I must be missing something but I don't see how that's a problem. Why can't
                                        HTML be used for a web service representation?


                                        -Mike Schinkel
                                        http://mikeschinkel.com
                                      Your message has been successfully submitted and would be delivered to recipients shortly.