RE: URIs, content adaptation, DISelect and XSLT

 Hi Dave,

> My question what how does the server know what to do with the chunk
URIs and how are these generated in the first place.
In our case, 
1- a request comes to the portal
2- the request headers are used to determine whether chunking is needed
and if there are cached chunks available
3- if yes, the first chunk is returned, which has been cached according
to the request headers and any user policies. This chunk contains a link
to the second chunk. For a given resource, there are multiple chunks
cached, for each device x policy combination (e.g. premium or adult
content will generate two possible responses)
4- if no, a Java/XSLT process chunks the page and generates link URIs
between them, writing the chunks to cache with those URIs

> What happens if the user bookmark's a chunk URI instead of the
published URI?
Then the chunk is returned, with links to the next and/or previus chunks
as appropriate.

Cheers
Kevin


-----Original Message-----
From: Dave Raggett [mailto:dsr@w3.org] 
Sent: 12 December 2007 14:42
To: Smith, Kevin, VF-Group
Cc: public-uwa@w3.org
Subject: RE: URIs, content adaptation, DISelect and XSLT

On Wed, 12 Dec 2007, Smith, Kevin, VF-Group wrote:

> HI Dave,
>
> From our own experience we haven't needed to publish the URI of a 
> chunk: content is chunked based on delivery context and a URI 
> created for each chunk. These URIs are only used to navigate 
> between chunks and are not used to access a chunk directly (e.g. 
> via search). So an end user would only discover 
> www.example.org/sports.xml as an entry point to the page, and not 
> www.example.org/sports.xml?chunk=2 . Due to the wide range of 
> delivery contexts the caching mechanism for these chunks involves 
> many 'vary' commands (on MSISDN, device name, bearer etc.) so 
> there's no value in exposing www.example.org/sports.xml?chunk=2 .
>
> Cheers
> Kevin

The published URI is to the website or application and is the same 
for everyone. When a page is split, the chunks are given URIs so 
that the browser can request the next chunk. My question what how 
does the server know what to do with the chunk URIs and how are 
these generated in the first place. What happens if the user 
bookmark's a chunk URI instead of the published URI?

For performance reasons, it would make sense to generate and cache 
all the chunks in one go rather than re-executing XSLT upon each 
chunk request. If the user bookmarked a chunk, then the server could 
check to see if it has a fresh cached copy, otherwise it could 
re-run XSLT to generate the chunks and then return the requested 
chunk. You might want to use the HTTP referred header (the exact 
name escapes me) to force return of the first chunk when 
appropriate. The chunks would be specific to particular classes of 
device, so you would need to reflect that in the naming scheme for 
chunks.

XSLT2 allows you to generate multiple output documents and as such 
could presumably be used to generate the chunks in a batch process, 
although I haven't tested that as yet.

  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Wednesday, 12 December 2007 15:08:01 UTC