- From: David Booth <david@dbooth.org>
- Date: Fri, 30 Mar 2012 21:18:05 -0400
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- Cc: Jeni Tennison <jeni@jenitennison.com>, Jonathan Rees <rees@mumble.net>, "www-tag@w3.org" <www-tag@w3.org>
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