Re: ACTION-434: Some notes on organizing discussion on WebApps architecture

These are certainly two different resources, and anyone can assert a relation between these two and give that relation a name. For instance, a representation of the second resource may have a link to the first one with some relation type (say, "up"). Other resources elsewhere on the web can make similar assertions about a relation between these two resources. It is really up to the client to decide which assertion it wants to use.

Subbu

On Oct 18, 2010, at 12:10 PM, Larry Masinter wrote:

> We're trying to extend web architecture to talk about applications,
> and the concepts/terminology we have seems to leave a gap, at least
> for me. Just having "representation" and "resource" leaves me without
> a way of talking easily about the relationship between
> 
> http://maps.google.com  and
> 
> http://maps.google.com/maps/place?cid=13506262960149713301&q=the+white+house&hl=en&ved=0CBAQhgUwAA&ei=nJm8TIfcB6i-jgO5_K2nBg&sig2=L4IeN4wW9YvHlGXDQkviKQ&sll=38.897096,-77.036545&sspn=0.020842,0.038418&ie=UTF8&ll=38.918017,-77.064199&spn=0,0&z=14&iwloc=A
> 
> Both of these URIs identify a "resource" which can have a
> "representation", and possibly multiple representations,
> which could vary based on the characteristics, capabilities
> and preferences of the receiver.
> 
> But what is the relationship of these two resources? I wanted
> to suggest that the former (http://maps.google.com) is an
> application, and the latter is also a resource, but it represents
> an application state description.
> 
> In this case, the relationship between the URIs is reflected
> in sharing an authority, although the latter adds path information
> and query parameters.
> 
> In some cases, some of the application state can be communicated
> in what we've been calling the "fragment identifier", because the
> state is implemented on the client side rather than server side.
> 
> In the web applications world, a "document" can be thought of as
> an application with limited functionality, namely, the function
> of being able to present itself to the user, and the "state" of the
> application is "scrolling the presentation to a particular part
> of the document and/or selecting that part".
> 
> Larry
> --
> http://larry.masinter.net
> 
> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@gbiv.com] 
> Sent: Sunday, October 17, 2010 2:23 PM
> To: Larry Masinter
> Cc: John Kemp; Appelquist, Daniel, VF-Group; jar@creativecommons.org; www-tag@w3.org
> Subject: Re: ACTION-434: Some notes on organizing discussion on WebApps architecture
> 
> On Oct 14, 2010, at 2:11 PM, Larry Masinter wrote:
> 
>> Well, I wonder if we might introduce another step between
>> "resource" and "representation" which is "application resource
>> in identified state", so that the representation isn't a
>> representation of the resource, but a representation of the
>> resource in that state.
> 
> Umm, what?  That would be terribly confusing and contrary to
> why I used the term representation in the first place (it is a
> representation by the origin server to the recipient of the state
> of that identified resource at the time of message generation).
> 
> You might be thinking of the hypermedia workspace -- the state of
> the user agent as it proceeds through an application, which may
> include hundreds of representations in various states of modification
> or use by the user agent.  Please don't confuse that with resource
> state or representation -- it is neither of those.  There is a huge
> architectural difference between what is known by the server (and
> available to others as a resource) and the current state of one
> user agent's workspace.  This is particularly important when the
> application uses a special resource to store the workspace state
> itself, such that it can be restored or shared with other devices.
> 
> ....Roy
> 
>

Received on Wednesday, 20 October 2010 03:51:34 UTC