W3C home > Mailing lists > Public > uri@w3.org > November 2008

RE: [whatwg] Proposing URI Templates for WebForms 2.0

From: Mike Schinkel <mikeschinkel@gmail.com>
Date: Sat, 1 Nov 2008 06:44:29 -0400
To: "'Mark Nottingham'" <mnot@mnot.net>
Cc: "'Ian Hickson'" <ian@hixie.ch>, "'Jerome Louvel'" <contact@noelios.com>, <whatwg@lists.whatwg.org>, "'URI'" <uri@w3.org>, "'REST Discuss'" <rest-discuss@yahoogroups.com>
Message-ID: <034a01c93c0e$d17934c0$6702a8c0@Guides.local>

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@mnot.net] 
Sent: Saturday, November 01, 2008 5:51 AM
To: Mike Schinkel
Cc: 'Ian Hickson'; 'Jerome Louvel'; whatwg@lists.whatwg.org; '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/
Received on Saturday, 1 November 2008 10:45:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:41 GMT