Re: [wsrp-interfaces] Groups - CacheableResources.html uploaded

[Michael Freedman <michael.freedman@oracle.com>]

Unfortunately, I don't think the newly added line:
"As a result, the resource generation SHOULD only depend on the 
PortletContext, SessionContext and the explicitly supplied resourceState."

is clear enough.  First off I assume you mean RuntimeContext not 
SessionContext as the session info seems to be carried in RC and I think 
resources should have access to the other RC data.  Secondly, isn't 
"explicitly supplied resourceState" too restrictive and doesn't it need 
to be qualified to the ResourceParams?  I.e. resourceState is a field in 
ResourceParams and hence this might be interpreted as limiting you from 
access/depending on the other "extra" resource parameters.  And as for 
the shared parmeters -- defined in MimeRequest, won't the resource need 
to access most of these? 

In the end I think I/we need to reverse ourselves and provide an 
explicit definition of what you can't depend on namely 
NavigationalContext.  Maybe we can finesse WS and Mode in that we don't 
entirely guarantee the consumer preserve these -- i.e. the portlet can 
depend on these (meaning will supply real value for these) but the 
consumer is encouraged to do this in a way that doesn't significantly 
impact cacheability.

As for the "portlet" level: I think the following sentence needs 
additional clarification:
"These restrictions apply not only to the resource directly referenced, 
but also to any secondary resources the resource references."

Should be:
"These restrictions apply not only to the resource directly referenced, 
but also to any secondary resources the resource references unless such 
reference sets a value of "full" at which point that reference and its 
follow on references adhere to the tighter restrictions".

I.e. you can always go to a tighter level but never a looser one.
 
And the last level "page":
The sentence:
"This ensures the Consumer will place the state it needs for such 
rewriting on the URI which the user agent will use to request the 
resource from it."

Might better be stated:
"This allows the Consumer to place the state it needs for such rewriting 
on the URI which the user agent will use to request the resource from it."

I.e. the way it is currently worded assumes a single implementation 
style vs. one we want to reserve/prefer.
     -Mike-


richt2@us.ibm.com wrote:

>The document revision named CacheableResources.html has been submitted by
>Rich Thompson to the WSRP Interfaces SC document repository.  This document
>is revision #1 of CacheableResources.html.
>
>Document Description:
>
>
>View Document Details:
>http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/document.php?document_id=22767
>
>Download Document:  
>http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/22767/CacheableResources.html
>
>Revision:
>This document is revision #1 of CacheableResources.html.  The document
>details page referenced above will show the complete revision history.
>
>
>PLEASE NOTE:  If the above links do not work for you, your email application
>may be breaking the link into two pieces.  You may be able to copy and paste
>the entire link address into the address field of your web browser.
>
>-OASIS Open Administration
>  
>