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/

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

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/

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

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

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/

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/01326831\
99/

Cheers (and good night),

--
Mark Nottingham     http://www.mnot.net/

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

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

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

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.

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

@Ian>>This might be a good time to bring the FAQ to people's attention -- it
covers what we ask people to go through when proposing new features:
>>
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_t
o_the_spec.3F

In my case, unfortunately, I don't have anyone paying me to participate so
my own personal financial requirements don't allow me to perform the
exhaustive research you are requesting. By requiring that you effectively
disenfranchise all those like myself who are not paid to participate and
thus have only a limited amount of time to be involved.

That is an effect of your process; was that intended?

Anyway, so please consider me to be one of the "authors and implementors"
your process refers to.

>> Why isn't the current form submission mechanism, with a redirect on the
server-side, not acceptable?

Two main reasons:

1.) Use cases where the person writing the form is not technically in
control of the server and where Javascript is unavailable and the percentage
of places where these use-cases exist are growing rapidly because of social
media and content management systems.

2.) Performance best practices frown on it:
http://developer.yahoo.com/performance/rules.html#redirects

Snell>>>> FYI... I've put together a quick prototype example [1] of a html
form
Snell>>>> using a URI Template [2].  The processing of the template is
performed
Snell>>>> in the onsubmit event of the form.
Ian>> This is great -- why is it not enough?

I keep saying "where Javascript is unavailable and the percentage of places
where these use-cases exist are growing rapidly because of social media and
content management systems" but you are not acknowledging. Are you
implicitly discrediting that as a concern, or have you missed those comments
of mine?

>> Because it adds significant complexity to the browser platform, without
really adding new functionality.

Significant? Srsly?  Seems to me we are talking about simply a URI Template
variable substitution.  Since it is *easy* to do in Javascript how can it be
adding "significant complexity" to the browser platform?  It seems your two
points are in direct contradiction; how are they not?

So, may I ask, who are the representatives of the browser platforms who
could give their feedback on this matter?

>> Why would scripts preclude accessibility?

See Al Gilman excellent response.

>> And are you really expecting search engines to fill in forms that would
use templates?

YES!!  Why would they not, if they could?

>> Something that can't be done without the feature.

When the use-case is no access to the server and only Javascript then this
use-case can't be done.

When the members of the web team say NO REDIRECTs on performance grounds, it
can't be done.

>> Something that allows authors to write applications that make users say
"wow!", which they can't do today.

URI Templates in forms would make core devs on content management systems
and frameworks go WOW once they realized what it can empower.  I'm
soliciting such feedback on Twitter:
http://twitter.com/mikeschinkel/status/985784895

>> There are many many gaps, why is this an important one to fill?

For the reasons given and because it makes URL templates declarative.

>> TBL did exactly what we're suggesting you do -- he wrote his own spec,
wrote his own client, and wrote his own server, and put it out there. He
didn't wait for a Standards Process to give him a stamp of approval.

And TBL worked for CERN, an organization that allowed lots of time to pursue
such interests. I instead am a working web developer and can't afford to go
off on such paths, I just need things to work better for which it has become
clear this standards process is a huge impediment.

>> Why not just provide links, or use a redirect?

Reasons already given.

>> What if the URI you have to compute is more complicated than just
substitution, like some parts being dependent on others, or needing
calculation, or whatnot?

HTML doesn't any never will handle 100% of use-cases; that's actually one of
the things that is good about it; it forces people to deal with constraints.
Unfortunately the constraints currently in place cause web developers to
frequently create URLs that machines can easily understand but that are
foreign to most humans. Adding URI Templates would loosen those contraints
and give web developers the ability to create human friendly URLs in a more
robust manner (i.e. not requiring Javascript.)

URI Templates would be no different than HTML, i.e. it would have
constraints. Handing 90% is 90% better than we have right now.

>> What if the user types something that isn't supported by weather.com,
like
the string "x"?

HTTP handles that elegantly; 404.

>> Also, why can't you just do:
>>   <form method="get" action="http://www.weather.com/search/enhanced">
>>    <input type="text" name="where"/>
>>    <input type="submit" value="Check Weather!">
>>   </form>

So obvious it hurts: Because I don't current control Weather's server and
they have no http://www.weather.com/search/enhanced URL.

>> I don't really follow what you're saying here. I see no practical
difference between URI templates and normal forms in terms of Google
crawling the results.

"Normal forms?"  Google is not going to try to parse out javascript code
that is custom to a website nor "user added" form attributes.

Also, adding a template attribute to a form element w/o it being in spec
causes it to fail validation; I thought validation was a holy grail but you
are instead suggesting we write HTML that doesn't validate?  Why only argue
for validation when it is convenient?

>> I don't think anyone is denying that it is useful in certain cases. The
question is whether it will be used widely enough to make it worth it.

What's more important; critical in 5% of cases or nice-to-have in 50% of
cases?


-Mike Schinkel
http://mikeschinkel.com

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

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

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

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

I agree with Steve.

A test harness for REST-over-HTTP could be valuable though; however it
can't be ignorant of media-types. How can such a test harness assess
HATEOAS without knowledge of the media-type exchanged? Without
knowledge of HATEOAS, the test harness is unable to traverse the links
between steady states.

Some problems come to mind. In order to assess REST-over-HTTP,
resource state changes must be made. In many, perhaps most, test
subjects this will be either impossible (due to access control
restrictions) or undesirable (filling a site with dummy data). The
Code-on-Demand constraint further complicates the testability of
subjects, as it reduces visibility.

Given the necessity to have knowledge of many media-types, I suspect
this would not be a trivial development. Good idea though (my
http-headers-status diagram grew out of just such a test suite,
although that was very application-specific).

Alan

On Fri, Nov 7, 2008 at 2:34 PM, Steve Bjorg <steveb@...> wrote:
> I'm not aware of any, but from your description, it sounds a HTTP test
> harness, not REST.
> - Steve
> --------------
> Steve G. Bjorg
> http://wiki.mindtouch.com
> http://twitter.com/bjorg
> On Nov 7, 2008, at 4:42 AM, Sebastien Lambla wrote:
>
> Hi,
>
> I had an idea a while ago. As I'm writing a REST enabler toolkit, and as i
> know others do exist too, it would be of great help to have a test harness
> to ensure valid (http / webarch) behavior.
>
> What I'm thinking of is a bunch of specifications for various areas to be
> implemented using an http or rest toolit, with an automated client checking
> for accurate responses.
>
> For example, the following would be a specification:
>
> Generic resources
> =============
> A generic resource /customer({id}) is exposed as an xml represetnation, a
> json representation and an html representation. Content-type negotiation is
> supported on such resource. Format-specific URIs exist at
> /customer({id}).html, /customer({id}).json and /customer({id}).html
>
>
> Acceptance criterias
> - A request to /customer(22) with Accept:
> application/xml;q=0.9,application/json triggers a 200 with Content-Type:
> application/json and Content-Location: /customer(22).json
> - A request to /customer(22) with Accept: */* triggers a 300 Multiple
> representations
> - A request to /customer(22).html with Accept: text/html triggers a 200
> - A request to /customer(22).html with Accept: application/json triggers xxx
>
>
> I'm building integration tests around my API that follow such a pattern, but
> having a common test suite for any API that has an implementation of such
> test harness would be invaluable.
>
> Is there such a harness and I missed it? Would anyone be interested in
> working on such harness?
>
> Seb
>
>

Alan,

I would imagine there is a reasonable good test surface for HTTP even
without knowledge of content-types.  Your diagram is a great resource
for this! (btw, did you ever get help on converting it to SVG?)

For instance, OPTIONS could be used to retrieve the list of supported
HTTP methods.  If GET is among them, check if a ETag response header
is present.  If so, does the server respond with 204 No Content when a
matching If-None-Match request header is present.  Similarly, if PUT
is supported, try If-Match header, and so forth.

Although, none of this has anything to do with REST, such a litmus
test would be very relevant to WOA implementers.

- Steve

--------------
Steve G. Bjorg
http://wiki.mindtouch.com
http://twitter.com/bjorg

On Nov 7, 2008, at 7:25 AM, Alan Dean wrote:

> I agree with Steve.
>
> A test harness for REST-over-HTTP could be valuable though; however it
> can't be ignorant of media-types. How can such a test harness assess
> HATEOAS without knowledge of the media-type exchanged? Without
> knowledge of HATEOAS, the test harness is unable to traverse the links
> between steady states.
>
> Some problems come to mind. In order to assess REST-over-HTTP,
> resource state changes must be made. In many, perhaps most, test
> subjects this will be either impossible (due to access control
> restrictions) or undesirable (filling a site with dummy data). The
> Code-on-Demand constraint further complicates the testability of
> subjects, as it reduces visibility.
>
> Given the necessity to have knowledge of many media-types, I suspect
> this would not be a trivial development. Good idea though (my
> http-headers-status diagram grew out of just such a test suite,
> although that was very application-specific).
>
> Alan
>
> On Fri, Nov 7, 2008 at 2:34 PM, Steve Bjorg <steveb@...>
> wrote:
>> I'm not aware of any, but from your description, it sounds a HTTP
>> test
>> harness, not REST.
>> - Steve
>> --------------
>> Steve G. Bjorg
>> http://wiki.mindtouch.com
>> http://twitter.com/bjorg
>> On Nov 7, 2008, at 4:42 AM, Sebastien Lambla wrote:
>>
>> Hi,
>>
>> I had an idea a while ago. As I'm writing a REST enabler toolkit,
>> and as i
>> know others do exist too, it would be of great help to have a test
>> harness
>> to ensure valid (http / webarch) behavior.
>>
>> What I'm thinking of is a bunch of specifications for various areas
>> to be
>> implemented using an http or rest toolit, with an automated client
>> checking
>> for accurate responses.
>>
>> For example, the following would be a specification:
>>
>> Generic resources
>> =============
>> A generic resource /customer({id}) is exposed as an xml
>> represetnation, a
>> json representation and an html representation. Content-type
>> negotiation is
>> supported on such resource. Format-specific URIs exist at
>> /customer({id}).html, /customer({id}).json and /customer({id}).html
>>
>>
>> Acceptance criterias
>> - A request to /customer(22) with Accept:
>> application/xml;q=0.9,application/json triggers a 200 with Content-
>> Type:
>> application/json and Content-Location: /customer(22).json
>> - A request to /customer(22) with Accept: */* triggers a 300 Multiple
>> representations
>> - A request to /customer(22).html with Accept: text/html triggers a
>> 200
>> - A request to /customer(22).html with Accept: application/json
>> triggers xxx
>>
>>
>> I'm building integration tests around my API that follow such a
>> pattern, but
>> having a common test suite for any API that has an implementation
>> of such
>> test harness would be invaluable.
>>
>> Is there such a harness and I missed it? Would anyone be interested
>> in
>> working on such harness?
>>
>> Seb
>>
>>

Alan,

your diagram certainly is one of the reasons that leads me to believe that
such a test harness / architecture specification would be valuable. It helps
implementers clarify and perfect their implementations.

I absolutely second your opinion on content-types, but I believe that, for
the sake of implementing such a test harness, a simple parser on the test
harness and html-producing on the server could be used.

I do not argue for a test harness to prove the Restfulness of a platform,
but one to validate scenarios that are needed as a pre-requirement to
implement REST: conneg, authentication, correct usage of status codes,
caching, correct handling of error scenarios such as the ones highlighted in
your diagram.

Steve,

very good scenario as well. There are quite a few around those areas that
would be an invaluable resource to implement an http server correctly. I do
believe that such a blueprint of a REST architecture to be implemented by
framework implementers could serve the REST community as well as the
implementers.

I do prefer Resource oriented architecture to WOA, but I can see a semantic
debate coming up that lack of time won't let me entertain just yet.

Seb

--------------------------------------------------
From: "Alan Dean" <alan.dean@...>
Sent: Friday, November 07, 2008 3:25 PM
To: "Steve Bjorg" <steveb@...>
Cc: "Sebastien Lambla" <seb@...>; <rest-discuss@yahoogroups.com>
Subject: Re: [rest-discuss] REST Server API test harness?

> I agree with Steve.
>
> A test harness for REST-over-HTTP could be valuable though; however it
> can't be ignorant of media-types. How can such a test harness assess
> HATEOAS without knowledge of the media-type exchanged? Without
> knowledge of HATEOAS, the test harness is unable to traverse the links
> between steady states.
>
> Some problems come to mind. In order to assess REST-over-HTTP,
> resource state changes must be made. In many, perhaps most, test
> subjects this will be either impossible (due to access control
> restrictions) or undesirable (filling a site with dummy data). The
> Code-on-Demand constraint further complicates the testability of
> subjects, as it reduces visibility.
>
> Given the necessity to have knowledge of many media-types, I suspect
> this would not be a trivial development. Good idea though (my
> http-headers-status diagram grew out of just such a test suite,
> although that was very application-specific).
>
> Alan
>
> On Fri, Nov 7, 2008 at 2:34 PM, Steve Bjorg <steveb@...> wrote:
>> I'm not aware of any, but from your description, it sounds a HTTP test
>> harness, not REST.
>> - Steve
>> --------------
>> Steve G. Bjorg
>> http://wiki.mindtouch.com
>> http://twitter.com/bjorg
>> On Nov 7, 2008, at 4:42 AM, Sebastien Lambla wrote:
>>
>> Hi,
>>
>> I had an idea a while ago. As I'm writing a REST enabler toolkit, and as
>> i
>> know others do exist too, it would be of great help to have a test
>> harness
>> to ensure valid (http / webarch) behavior.
>>
>> What I'm thinking of is a bunch of specifications for various areas to be
>> implemented using an http or rest toolit, with an automated client
>> checking
>> for accurate responses.
>>
>> For example, the following would be a specification:
>>
>> Generic resources
>> =============
>> A generic resource /customer({id}) is exposed as an xml represetnation, a
>> json representation and an html representation. Content-type negotiation
>> is
>> supported on such resource. Format-specific URIs exist at
>> /customer({id}).html, /customer({id}).json and /customer({id}).html
>>
>>
>> Acceptance criterias
>> - A request to /customer(22) with Accept:
>> application/xml;q=0.9,application/json triggers a 200 with Content-Type:
>> application/json and Content-Location: /customer(22).json
>> - A request to /customer(22) with Accept: */* triggers a 300 Multiple
>> representations
>> - A request to /customer(22).html with Accept: text/html triggers a 200
>> - A request to /customer(22).html with Accept: application/json triggers
>> xxx
>>
>>
>> I'm building integration tests around my API that follow such a pattern,
>> but
>> having a common test suite for any API that has an implementation of such
>> test harness would be invaluable.
>>
>> Is there such a harness and I missed it? Would anyone be interested in
>> working on such harness?
>>
>> Seb
>>
>>
>

I agree: a generic HTTP test harness would have value too, aside from REST.

A couple of people tried to help out with the conversion to SVG but to
no avail yet. What I really need is a way to automate the process, not
do it manually. That, or MS fix up the support for SVG in Visio ...

Alan

On Fri, Nov 7, 2008 at 3:46 PM, Steve Bjorg <steveb@...> wrote:
> Alan,
>
> I would imagine there is a reasonable good test surface for HTTP even
> without knowledge of content-types.  Your diagram is a great resource for
> this! (btw, did you ever get help on converting it to SVG?)
>
> For instance, OPTIONS could be used to retrieve the list of supported HTTP
> methods.  If GET is among them, check if a ETag response header is present.
>  If so, does the server respond with 204 No Content when a matching
> If-None-Match request header is present.  Similarly, if PUT is supported,
> try If-Match header, and so forth.
>
> Although, none of this has anything to do with REST, such a litmus test
> would be very relevant to WOA implementers.
>
> - Steve
>
> --------------
> Steve G. Bjorg
> http://wiki.mindtouch.com
> http://twitter.com/bjorg
>
> On Nov 7, 2008, at 7:25 AM, Alan Dean wrote:
>
>> I agree with Steve.
>>
>> A test harness for REST-over-HTTP could be valuable though; however it
>> can't be ignorant of media-types. How can such a test harness assess
>> HATEOAS without knowledge of the media-type exchanged? Without
>> knowledge of HATEOAS, the test harness is unable to traverse the links
>> between steady states.
>>
>> Some problems come to mind. In order to assess REST-over-HTTP,
>> resource state changes must be made. In many, perhaps most, test
>> subjects this will be either impossible (due to access control
>> restrictions) or undesirable (filling a site with dummy data). The
>> Code-on-Demand constraint further complicates the testability of
>> subjects, as it reduces visibility.
>>
>> Given the necessity to have knowledge of many media-types, I suspect
>> this would not be a trivial development. Good idea though (my
>> http-headers-status diagram grew out of just such a test suite,
>> although that was very application-specific).
>>
>> Alan
>>
>> On Fri, Nov 7, 2008 at 2:34 PM, Steve Bjorg <steveb@...> wrote:
>>>
>>> I'm not aware of any, but from your description, it sounds a HTTP test
>>> harness, not REST.
>>> - Steve
>>> --------------
>>> Steve G. Bjorg
>>> http://wiki.mindtouch.com
>>> http://twitter.com/bjorg
>>> On Nov 7, 2008, at 4:42 AM, Sebastien Lambla wrote:
>>>
>>> Hi,
>>>
>>> I had an idea a while ago. As I'm writing a REST enabler toolkit, and as
>>> i
>>> know others do exist too, it would be of great help to have a test
>>> harness
>>> to ensure valid (http / webarch) behavior.
>>>
>>> What I'm thinking of is a bunch of specifications for various areas to be
>>> implemented using an http or rest toolit, with an automated client
>>> checking
>>> for accurate responses.
>>>
>>> For example, the following would be a specification:
>>>
>>> Generic resources
>>> =============
>>> A generic resource /customer({id}) is exposed as an xml represetnation, a
>>> json representation and an html representation. Content-type negotiation
>>> is
>>> supported on such resource. Format-specific URIs exist at
>>> /customer({id}).html, /customer({id}).json and /customer({id}).html
>>>
>>>
>>> Acceptance criterias
>>> - A request to /customer(22) with Accept:
>>> application/xml;q=0.9,application/json triggers a 200 with Content-Type:
>>> application/json and Content-Location: /customer(22).json
>>> - A request to /customer(22) with Accept: */* triggers a 300 Multiple
>>> representations
>>> - A request to /customer(22).html with Accept: text/html triggers a 200
>>> - A request to /customer(22).html with Accept: application/json triggers
>>> xxx
>>>
>>>
>>> I'm building integration tests around my API that follow such a pattern,
>>> but
>>> having a common test suite for any API that has an implementation of such
>>> test harness would be invaluable.
>>>
>>> Is there such a harness and I missed it? Would anyone be interested in
>>> working on such harness?
>>>
>>> Seb
>>>
>>>
>
>

All,

Here is the presentation [1] that I will be giving at DDD7 [2] in two
weeks time and then taking on the road to the UK User Community (I've
already booked at MSR in Cambridge). Any feedback is welcome.

Regards,
Alan Dean

[1] http://tinyurl.com/ddd7-rest
[2] http://www.developerday.co.uk/

On 07.11.2008, at 16:14, Steve Bjorg wrote:

>
> If you plan on doing REST over HTTP, may I recommend WOA as a term?
> It's defined as WOA = SOA + WWW + REST.  Removes the ambiguity when
> talking about either an architectural style or an application of it
> to a specific environment.
>

I positively hate the term "WOA"; IMO it's the beginning of turning
something well-defined into the same meaningless pseudo-science we
have around "SOA".

Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

> - Steve
>
> --------------
> Steve G. Bjorg
> http://wiki.mindtouch.com
> http://twitter.com/bjorg