Re: pls change main validator form back to GET

Olivier Thereaux <ot@w3.org> wrote:

>1 - "strict" POST/GET with two forms
>2 - the hybrid system we have in 0.6.1, with one form (POST),
>    and the POST request is redirected to a GET request should
>    the POST be non-necessary.

Without stating my opinion on either of the options (I believe I have made
my opinion clear), and purely as points of information, there are also:

3 - Provide a JavaScript that onSubmit() alters the "method" attribute
    of the "form" element from "POST" to "GET" *iff* no file upload was
    selected.

    With JavaScript enabled, this provides for GET when GET is possible;
    and falls back to POST for both URI and Upload if JS is disabled.


4 - Provide two forms -- one with GET for URI and one with POST for
    File Upload -- and a JavaScript that onLoad will _hide_ these two
    forms and instead create the single form with an onSumbit handler
    as per #3 above.

    This option provides for GET in all cases where it is possible, but
    trades off Human Interface / Usability when JavaScript is disabled
    (option #3 trades off GET vs. POST).


5 - No File Upload at all on the front page -- pointing instead at
    /file-upload.html -- thus making GET an appropriate method.


6 - No form element on the front page at all -- pointing instead at
    /detailed.html and /file-upload.html -- and have these use GET or
    POST, respectively, as appropriate.


[ Still not stating opinion... ]:
>Strictly speaking these are two interpretations of the HTTP methods,

Not necessarily. Iff a "TAG Finding" carries force of fiat then, by the
policy we've traditionally adopted -- implement to the specs regardless of
what we think of them -- we _must_ use GET for everything except File
Upload regardless of what is or isn't supported by the HTTP spec because
the TAG's Finding overrules it.

Iff that is the case then it doesn't matter that the TAG Finding is just
using one, out of several possible, interpretations of the HTTP specs...

...because the mere fact of the TAG choosing that interpretation is then
binding; the TAG has mandated (which, BTW, is within it's charter) which
interpretation is the "correct" one out of the plural possible.


Unfortunately, I was not able to find anything in W3C Process or the TAG
Charter that tells me what force or authority a "TAG Finding" carries. It
doesn't even seem to clarify what authority the TAG as a whole carries (but
I am not intimately familiar with W3C Process, so that may not mean very
much).

Once the Web Architecture document is published the issue becomes much
clearer because that will have been subject to the full TR process and is
then a Recommendation. But since this is not the case yet, the impact of
the "TAG Finding" is not clear.


But, of course, that the TAG has published this "Finding" -- and stated
it's intent to include that "Finding" in the Web Architecture document once
it /does/ get published -- must be taken into account as at the very least
a strong guideline for the future.

_Regardless_ of what my opinion of this issue may be!


>I'm certain we can have a cool-headed discussion among smart people [...]

Of the many traits I have been ascribed over the years, "cool-headed" does
not figure prominently on the list... :-)


>[...] and reach consensus (remember, W3C is a consensus based org?)...

See above for why consensus may not be relevant to this issue.




-- 
When I decide that the situation is unacceptable for me, I'll simply fork
the tree!   I do *not* appreciate being enlisted into anyone's holy wars,
so unless you /really/ want to go *way* up on my personal shitlist, don't
play politics in my vicinity!                   -- Alexander Viro on lkml

Received on Monday, 2 December 2002 21:45:42 UTC