RE: yet another resource/representation diagram

> From:  Jonathan Rees
> 
> Inspired by some comments Henry made about conneg at the recent TAG  
> meeting I've made a third diagram to attempt to fit the conflicting  
> theories together; see [1].

Thanks for doing this work and creating this diagram.  I'm trying to digest it, but one thing I'm running into is that a couple of the arrows are not labeled: 

 - from 'Boothian "ftrr"' to 'Encoding of information thing';

 - from 'network service (a la 2616)' to 'Response from service'

What relationships were these intended to be?

I liked the attempts in Michael Hausenblas's diagram[7] to indicate subclass relationships between the classes, as I thought they added a lot toward understanding the classes.  Might subclassing be added to yours?

> 
> This is a bit more focused than diagram #2 [2], and it no 
> longer talks  
> about URIs, just the things that might or might not be named.
> 
> The boxes are classes and the arrows are properties that might hold  
> between members of the classes. 3D boxes are for things that have a  
> time dimension of any kind.
> 
> The theories to be reconciled are:
>    1. TimBL "generic resources" [3]
>    2. REST [4]
>    3. David Booth ftrr [5]
>    4. HTTP [6]
> 
> I think the overall diagram makes a plausible story.
>    - a single GR doesn't "know" (commit to, model) what  
> representations are associated with its states

One thing I notice about the GR description in [3] is that in comparing GR to ftrr[5], GR does not seem to describe any way for representations to depend on request inputs other than those that might select different languages or content types.  In other words, even aside from different languages or content types, different requests -- in essence, different inputs to a CGI script -- may produce different outputs.  It isn't clear whether TimBL intentionally restricted the notion of GR this way -- rather like an abstract document -- or he simply didn't bother to call out this additional source of variability.  The GR page lists three "Dimensions of genericity": 

 - Time
 - Language
 - Representation (i.e., 'using different Content-types')

As GR is described, ftrr acknowledges a fourth "dimension of genericity":

 - Request (an input in creating the response)

>    - REST is very similar to David's ftrr - difference lies in  
> treatment of request headers (e.g. User-agent)

What difference do you mean?  AFAIK ftrr corresponds very closely to REST.

>    - a REST resource, or ftrr, commits at each time to some 
> particular set of representations

Yes.  As I pointed out in [8]: 'If you take Roy's definition to be essentially "a function from time to representation sets", then the ftrr:IR definition is pretty much equivalent to Roy's definition.  The function in Roy's definition is pretty much a curried[9] version of the function in the ftrr:IR definition.'

>    - thus there many REST resources that are all "faithful" to a  
> single GR in the sense of delivering valid representations of 
> the GR's  
> states. Different granularity or identity criteria for the 
> two classes.

Not sure what you mean here.  Are you pointing out that some REST resources may be more coarse grained versions of a single GR?  But that would also be said of GRs in relation to other GRs -- different granularity of "genericity" -- so I don't know what point you're trying to convey here.

>    - GRs and REST resources are not inherently physically embodied
>    - REST and ftrr are Platonic ideals (models) of hypothetical or  
> real response sources
>    - HTTP response sources are physically embodied, thus very  
> different from both GRs and REST
>    - but an HTTP response source can be "faithful" to a GR or a REST  
> resource by implementing it correctly

Hmm.  I see the difference between a hypothetical response source and an actual response source -- essentially the difference between saying "there *might* be one" and "there *is* one" -- but I'm not entirely convinced that an HTTP response source should not also be viewed as a Platonic ideal, since the protocol definition doesn't care at all about real things, it describes a model also.  Even the notion of "server" in RFC2616 seems to me like a Platonic ideal.

Why do you see this notion of Platonic ideal as being an important differentiator?

>    - an HTTP response source can do all sorts of things that are not  
> modeled by GR or REST, such as deliver 3xx, 4xx, 5xx responses

Yes, it clearly is a different beast.  It has broader functionality than ftrr, GR or REST, and is used to *implement* them.

>    - RFC 2616 permits resources that are "network services" - it is  
> not natural to talk about these having 'states' or 
> 'representations' -  
> not clear whether such services a REST resources at all - I don't  
> think they should be considered so (service: random number 
> generator,  
> webcam, database query?)

I don't find the term "network services" when I search RFC2616.  To what section are you referring?

>   - not clear whether two distinct GRs can correspond to the 
> same REST  
> resource. I think not since then they would have incommunicable  
> 'essential characteristics'
> 
> Please don't jump on my terminology... it's easily changed. The main  
> point is that the four theories are about different kinds of things  
> with different identity criteria, but they can be related to one  
> another in a sensible way.
> 
> I think it's important to understand this story well before 
> attempting  
> to answer any questions about "identification".
> 
> Jonathan
> 
> [1] http://www.w3.org/2001/tag/awwsw/jar-diagram-3.pdf
> [2] 
> http://esw.w3.org/topic/AwwswHome?action=AttachFile&do=get&tar
> get=URI-representation-resource-unified.pdf
> [3] http://www.w3.org/DesignIssues/Generic.html
> [4] http://www.ics.uci.edu/~fielding/pubs/webarch_icse2000.pdf
> [5] 
> http://www.w3.org/mid/184112FE564ADF4F8F9C3FA01AE50009FCF22AD6
> 76@G1W0486.americas.hpqcorp.net
> [6] http://www.ietf.org/rfc/rfc2616.txt

[7] Michael's diagram:
http://esw.w3.org/topic/AwwswVocabularyDependencies

[8] http://lists.w3.org/Archives/Public/public-awwsw/2008Apr/0047.html

[9] http://en.wikipedia.org/wiki/Currying

[10] http://www.w3.org/DesignIssues/NameMyth.html




David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.

Received on Sunday, 8 March 2009 02:44:22 UTC