Re: Updating Change Proposals for ISSUE-195 form-http-req

On Wed, Jul 25, 2012 at 10:12 PM, Sam Ruby <rubys@intertwingly.net> wrote:
> Top posting as my suggestions are generic.
>
> If including this in HTML5 and not in some subsequent version of the
> specification is important to you, I would suggest two things:
>
> 1) Provide first hand descriptions of user requirements.  Don't simply
> describe second-hand a "twitter-style" service that hypothetically could
> make use of the proposal that you describe; actually get input from Twitter
> itself (Twitter clearly being an example here, substitute as required).  For
> best results, get a statement that they would make use of the feature if it
> were provided.  Ideally get them to provide quantification in any form
> you/they see fit as to what the value is.

Ok, perhaps i'm being a little too proactive now. I suggested to
append the updated proposal with more "use cases" as this was one of
the initial arguments raised against the first draft. I explicitly
responded to that criticism within the current revision which has not
been challenged or refuted.

Your comments regarding further information seem to indicate that
there is, or will be, issue taken with the validity of the use cases
presented and they will be disregarded. Since the cases i have brought
forward are low-level abilities and not in terms of HTML user actors,
i took this to imply that for a use case to be deemed valid it must
conform to such idiomatic pretense. Therefore the proactive approach i
proposed was to apply a "case study" methodology by reifying the
generic use cases into higher level end-user scenarios. This is a
contrived process as you have noted.

To look at this further, can you imagine being asked to produce use
cases for describing why someone would want to use GET or POST? When
the protocol semantics are being disregarded the question becomes
meaningless. The proposal to provide case studies is not to satisfy
deficient use cases or user requirements, but to illustrate by
example.

If we look at the specification of XHR, why does it provide the
ability to set methods other than GET and POST if they should never be
needed? Why does it provide ability to set headers if they have no use
cases of their own? Why does it provide authentication hooks if these
serve no purpose?

All of these "use cases" are unsatisfied within HTML as a language yet
afforded to Javascript. The primary use case is that of declarative
ability with all the benefits that come with declarative over
imperative programming, and that Javascript is not and should be a
prerequisite for using HTML or the web.

I believe these use cases and arguments are sufficiently elucidated
with the proposal.

>
> 2) Don't include anything in your proposal that isn't specifically in
> response to the requirements that you have gathered.  Background on this: if
> you identify 8 things in your proposal and somebody object to the 5th thing
> for whatever reason, the chairs will generally not attempt to create a
> proposal on your behalf that gerrymanders around that specific problem.
> Instead, you are encouraged to work with others before hand to identify and
> address problems and build consensus before we get to the point of a survey.
>

Yes, no problem, i understand the role of the chairs and the
requirements on proposals. Having updated the proposal in response to
the counter proposal and chair review i have worked to answer all
raised problems towards reaching consensus. There has been no further
concerns raised yet i am being asked to update the proposal again. I
have provided my own critical review however the only remaining issues
i can see is with regards to the nebulous "hand waiving" concerns
solely described as "this is too complicated" or "this is totally
insecure". These arguments are totally unfounded and so irrefutable
due to the lack of substance.

I ask for direction from the chairs on how to proceed. It is my belief
that further work on my proposal would amount to an extraneous expense
of effort, however i am more that happy to do so in the pursuit of
pre-survey consensus.

Thanks,
Cameron Jones

Received on Thursday, 26 July 2012 13:09:23 UTC