RE: URIs, content adaptation, DISelect and XSLT

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

 



-----Original Message-----
From: public-uwa-request@w3.org [mailto:public-uwa-request@w3.org] On
Behalf Of Dave Raggett
Sent: 11 December 2007 11:38
To: public-uwa@w3.org
Subject: URIs, content adaptation, DISelect and XSLT 


This email considers the use of XSLT for content selection and asks 
whether there is missing functionality when it comes to accessing 
chunked pages, and suggests the need for updating the primer.

Consider someone wanting visit a website at http://www.example.com/. 
This has the same URI for everyone regardless of whether they are 
using a desktop browser, a screen reader or a mobile device.

Content adaptation is the process whereby the markup and associated 
resources delivered to the device can be made to depend on the class 
of the device, the specific device (e.g. John Smith's N81), or user 
preferences (e.g. Fiona Wright requires high contrast graphics and 
large text).

Whilst mobile devices are rapidly improving their technical 
characteristics, there remains a long tail of devices with limited 
memory. This introduces the need for reducing the size of a web 
page, or for breaking it into a sequence of smaller pages or chunks. 
The latter introduces the issue of what URIs are used to identify 
the chunks.

The Content Selection for Device Independence specification [1] 
together with the associated XPath Access Functions specification 
[2] provide a way to embed selection rules within markup, e.g.

   <p>The flooding was quite extensive.</p>
   <p sel:expr="dcn:cssmq-width('px') > 200">
     <object src="image1" sel:selid="artimg42"/>
   </p>
   <p>Many people were evacuated from their homes.</p>

where an image is only included if the display is wider than 200 
pixels wide. You can also markup a series of alternatives as in

   <sel:select>
     <sel:when expr="dcn:cssmq-width('px') > 200">
       <object sel:selid="pic42" src="image1"/>
     </sel:when>
     <sel:when expr="dcn:cssmq-color() > 4">
       <object sel:selid="pic42" src="image2"/>
     </sel:when>
     <sel:otherwise>
       <p sel:selid="pic42">Many people had to be evacuated.</p>
     </sel:otherwise>
   </sel:select>

where the first matching when element determines which content 
should be selected. The name space prefix (in this case "sel") must 
be declared, e.g. on the root element. More details are given in the 
primer [3].

The above approach inserts the selection rules into the content 
markup. Another approach is to separate the rules from the content 
altogether. This is possible via using the XPath access functions 
from within XSLT [4][5].

Getting back to the website example, it would be straightforward to 
configure the webserver to map requests for http://www.example.com/ 
to the output from running XSLT on a specific file. An XSLT 
document can pull in markup from a content management system as 
needed to match the specific delivery context. Note that this 
approach doesn't need [1] as XSLT has equivalent mechanisms built 
in.

What's missing is a means to identify the URIs for specific chunks
when it is necessary to split content into a number of smaller 
pages. In principle, this can be achieved via a means to configure 
the server to pass the requested URI to the XSLT processor so that 
it is available to the XPath access functions used within the XSLT 
document.

Do we need to define a new XPath access function to expose the 
requested URI and the implied chunk id as part of the delivery 
context or are existing mechansisms sufficient?

Eitherway, it would be valuable to update the primer [3] to explain 
how to use XSLT for content selection based upon the delivery 
context, and with examples of how to configure the server and 
content management system.

Please note that content selection is just one aspect of designing 
for multi-channel delivery. For instance, to reduce the cost of 
maintaining a website, you will probably want to use techniques that 
allow you to separate off what you want the web pages to do from all 
the messy details of how to achieve that on specific browsers. 
Another concern is how to manage different versions of assets such 
as images and text content, and how to support different members of 
the website team with their different roles in the production 
proces.

References:

[1] http://www.w3.org/TR/2007/CR-cselection-20070725/
[2] http://www.w3.org/TR/2007/CR-cselection-xaf-20070725/
[3] http://www.w3.org/TR/cselection-primer/
[4] http://www.w3.org/TR/2007/REC-xslt20-20070123/
[5] http://www.xml.com/pub/a/2002/04/10/xslt2.html

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

Received on Wednesday, 12 December 2007 12:41:01 UTC