Re: Classification of ISSUE-57 change proposals

Hi Noah,

On Fri, 2012-03-30 at 11:23 -0400, Noah Mendelsohn wrote:
> 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 
> [4]:
> 
> "Constraint: URIs Identify a Single Resource -- Assign distinct URIs to 
> distinct resources."

Be careful.  That is good, but simplistic advice.  

> 
> 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.

The fundamental problem with the admonition against using a single URI
for both a resource and its description is that: (a) it wrongly implies
that distinguishing between the two is universally important; and (b) it
ignores the fact that in general, no matter how precisely a URI is
defined, it will be ambiguous to an application that needs to make finer
distinctions.  The resource-vs-description axis is only one of a
potentially infinite number of axes along which an application may need
to make distinctions.

In other words, a resource-vs-description distinction will matter to
some applications and not others, and that is the *exact* same state of
affairs as for any other distinction along any other axis of potential
ambiguity: it will matter to some applications and not to others.

To put it simply: Every URI is inherently ambiguous to some applications
and unambiguous to others.  And that's okay.  However, we *can* design
the architecture to help *constrain* that ambiguity, and that's what a
URI definition does.

We won't have much hope in resolving this issue unless we come to grips
with this fundamental fact of life.

> 
> 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, 

Good call.  That's certainly worth considering.

> which presumably requires that one can reliable distinguish 
> resource representations from resource descriptions.

Oops!  No, it doesn't.

David

> 
> 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.
> 
> Noah
> 
> [1] http://www.w3.org/TR/webarch/summary.html
> [2] http://www.w3.org/TR/webarch/
> [3] http://www.w3.org/2001/tag/findings#approved
> [4] http://www.w3.org/TR/webarch/#pr-uri-collision
> [5] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
> 
> 
> 
> 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
> 
> 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Saturday, 31 March 2012 01:18:29 UTC