- From: Jonathan A Rees <rees@mumble.net>
- Date: Fri, 30 Mar 2012 11:56:06 -0400
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- Cc: Jeni Tennison <jeni@jenitennison.com>, "www-tag@w3.org" <www-tag@w3.org>
On Fri, Mar 30, 2012 at 11:23 AM, Noah Mendelsohn <nrm@arcanedomain.com> 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." > > 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. Hmm... I agree in spirit, but as an aside I quibble with the phrasing of the last part, and since terminology is really screwing us over I want to hit what you say hard. "Representation" remember is a war zone, with Roy using it one way (see REST and HTTPbis) and TimBL using it another. It is an instrument of propaganda. In Roy's view a description could very well be a representation; in TimBL's that is not enough. AWWW sits on the fence, not really taking a position, while httpRange-14 has been understood as saying all representations (or at least any representation that is retrieved) are to be content, so the scene is very confused. So be very careful of terminology. (In my opinion Roy has been inconsistent in agreeing to httpRange-14 and then turning around and putting an incompatible definition in HTTPbis.) I tend to give Roy priority in use of "representation", since REST is so well known and HTTPbis will have such prominent standing, and use "content" or "instance" in TimBL's preferred sense (i.e. encoding or shared properties, see note "generic resources and web metadata" which I annoyingly always trot out here, for what I think is meant). So here I think it would be better for you to say "content" rather than "representation". Also we are not talking about making a distinction. A representation can be *both* content *and* description. There are two orthogonal questions: (1) is it to be understood as content, and (2) is it to be understood as description. (And it might be neither, e.g. a depiction; and it could in *fact* be one or the other or both, without it being *understood* to be such.) But I agree otherwise. Not everyone gets this transparency idea though, which makes the discussion difficult. > 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. I think I agree with all of this. The constraints you list overlap with some of the desiderata in the ISSUE-57 overview http://www.w3.org/2001/tag/awwsw/issue57/latest/, which is where I was going to start, but I may have missed a few things, which we can add as we get going. I don't think we should assume that Web Architecture is Good, but it provides some useful starting points. Maybe you could take a crack at selecting the webarch points that bear on the question?... Best Jonathan > 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
Received on Friday, 30 March 2012 15:56:40 UTC