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

Re: [whatwg] Proposing URI Templates for WebForms 2.0

Expand Messages
  • Mark Nottingham
    I missed the second link, which does contain examples; apologies. The benefits you re talking about seem to be all related to having more flexibility in
    Message 1 of 25 , Oct 31, 2008
    • 0 Attachment
      I missed the second link, which does contain examples; apologies.

      The benefits you're talking about seem to be all related to having
      more flexibility in specifying URIs from forms. 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.

      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.

      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)?
      If it takes off, you can have the satisfaction of seeing it
      incorporated into HTML6...

      Cheers,


      On 01/11/2008, at 4:24 PM, Mark Nottingham wrote:

      > 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/
      >


      --
      Mark Nottingham http://www.mnot.net/
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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.