Re: pls change main validator form back to GET

On Tue, 2002-12-03 at 23:49, Terje Bless wrote:
> Dan Connolly <connolly@w3.org> wrote:
> 
> >On Mon, 2002-12-02 at 20:45, Terje Bless wrote: [...]
> >>>Strictly speaking these are two interpretations of the HTTP methods,
> >>Not necessarily. Iff a "TAG Finding" carries force of fiat [...]
> >
> >Consider the tag finding irrelevant.
> 
> Ok. But out of curiosity, what exactly is the authority of a TAG Finding?

They reflect decisions made by the TAG and review by
participants of www-tag.


> Are they purely informational until such time as they get incorporated into
> a WebArch REC?

A W3C REC generally carries more endorsement than a TAG finding;
I think the W3C validation services is, by agreement of its
operators, obliged to follow W3C RECs.

I'm not sure what you mean by "purely informational".
Perhaps you're asking whether TAG findings place any
obligations on you, or on the operation of the validation
service. I think the answer is no. That is: you might
find a TAG finding convincing; and if you don't find
it convincing, you're invited to say why not in www-tag.
But you're neither obliged to follow TAG findings
nor to send review comments to www-tag.


> Or is this something best left alone right now? :-)
> 
> 
> >It's [the HTML and HTTP] specs that provide the motivation for my
> >request; once again:
> >
> >[[[
> > The "get" method should be used when the form .... causes no
> > side-effects.
> >]]] -- <http://www.w3.org/TR/1999/
> >REC-html401-19991224/interact/forms.html#h-17.13.1>
> 
> Well, as Jim mentioned, whether the form on v.w3.org has "side-effects" is,
> at the very least, debatable.

Yes, as chair of the WG that produced that spec, I'm disappointed to
see that it's not sufficiently clear to readers such as yourself.

> As is, IMO, the definition of "side-effects"
> in the general case. Once man's side-effect is another man's idempotency.
> 
> In particular, the "check" CGI script is certainly idempotent, but it does
> have side-effects over and above what is usually expected of a GET (on,
> e.g., a static HTML file or a .shtml etc.).
> 
> 
> Apart from the two possible interpretations of the specs, this is also a
> case of a tradeoff between strict technical correctness and usability. As
> Jim brings up, the reason for the consolidated form is to improve
> usability. Multiple submit buttons for what, from a user perspective, is a
> single form -- and which appear to, but do not in fact, do the same thing
> -- is terrible human interface.

I disagree. (Gerald makes the counter-argument fairly
well in his message of 04 Dec 2002 06:49:11 +0100, so
I won't elaborate here.)

> Consider the failure modes of the two models for minute!
> 
> 
> >[[[ Implementors should be aware that the software represents the user
> >in their interactions over the Internet, and should be careful to allow
> >the user to be aware of any actions they might take which may have an
> >unexpected significance to themselves or others.
> >
> >In particular, the convention has been established that the GET and HEAD
> >methods SHOULD NOT have the significance of taking an action other than
> >retrieval. These methods ought to be considered "safe". This allows user
> >agents to represent other methods, such as POST, PUT and DELETE, in a
> >special way, so that the user is made aware of the fact that a possibly
> >unsafe action is being requested.
> >
> >Naturally, it is not possible to ensure that the server does not
> >generate side-effects as a result of performing a GET request; in fact,
> >some dynamic resources consider that a feature. The important
> >distinction here is that the user did not request the side-effects, so
> >therefore cannot be held accountable for them.
> >]]]
> >-- http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1
> 
> This is pure wishfull thinking on RFC 2616's part! No such convention has
> or had been established; RFC 2616 is trying to establish it.

Hmm... it would seem to me that the same sort of obligation of the
W3C validation service to be consistent with W3C RECs applies
to IETF Draft Standards, no?

The time to review/discuss/debate the contents of the HTTP 1.1
spec is behind us, no?

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Monday, 9 December 2002 12:15:12 UTC