Re: Classification of ISSUE-57 change proposals

Yes, thank you Jonathan. This is very helpful.

There's another dimension that I think would be useful to consider in 
classifying the proposals, though I'm not sure I understand the proposals 
sufficiently to do the detail work myself.

Specifically, I think it would be useful to look at the Constraints, 
Principles and Good Practices in Web Arch [2] and related TAG findings [3], 
and to make a little matrix the notes areas in which one proposal or 
another might fail to follow good practice. For example, Web Arch calls out 

"Constraint: URIs Identify a Single Resource -- Assign distinct URIs to 
distinct resources."

It's my intuition that some of the proposals skate close to the line on 
this one, using a single URI for both a resource and its description.

I think it's also worth considering "The Self-Describing Web" [5] finding, 
and satisfying ourselves that the representations returned per each 
proposal are indeed self-describing in the senses mandated by the finding. 
Specifically, this requires that there's a chain of specifications, 
starting with RFC 3986 that will allow one to correctly interpret any HTTP 
response, which presumably requires that one can reliable distinguish 
resource representations from resource descriptions.

So, this is a call to make a list of Web Architecture contraints, 
principles and good practices likely to be pertinent to the httpRange-14 
work, and from that to generate a small matrix highlighting areas in which 
particular proposals violate or come close to violating the letter or 
spirit of the "rules". If the matrix turns out to be empty, so much the 
better: that will assure us that all the proposals are pretty clean per 
WebArch, and that we can go on to prioritize them in other ways.

Thank you.



On 3/30/2012 10:58 AM, Jeni Tennison wrote:
> Jonathan,
> Thank you for all the work you're doing on this. The classification of the proposals into groups looks really helpful as a way of understanding the underlying intent of each without getting bogged down in their details.
> Cheers,
> Jeni

Received on Friday, 30 March 2012 15:23:49 UTC