RE: URIs, content adaptation, DISelect and XSLT

Hi Dave,

As we discussed on the call I can see definite 'separation of concern'
value to this approach, and as it enables a modular stylesheet (similar
to CSS) to be plugged in to existing content. This is less of a
migration step than DIAL which requires reauthoring in XHTML 2 (and
removes a dependency on XHTML 2 recommendation and tool support).

A couple of observations:
1- identifiers. It appears that the author would still need to indicate
which selection expressions were appropriate for which content. In the
example:

   <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>

Would be expressed in XSLT as

<!-- leaving out the dcn function definition for brevity-->
...
1 <xsl:template match="p">
2  <xsl:copy><xsl:apply-templates /></xsl:copy>
3 <xsl:if test="dcn:cssmq-width('px') > 200">
4   <p sel:expr="dcn:cssmq-width('px') > 200">
5     <object src="image1" sel:selid="artimg42"/>
6   </p>
7 </xsl:if>
8 </xsl:template match="p">
...

Line 1 matches on the context node for the paragraph, but in a document
with many paragraphs then we need to be more specific: 

By position - 
<xsl:template match="p[3]"> 
...but what if this is mutable, e.g. the content is aggregated from
multiple sources?

By text content:
<xsl:template match="p[.='The flooding was quite extensive.']"> 
...a bit messy and not practical for dynamic content (e.g. from a CMS)

If the author declares an identifier then we have a similar approach to
CSS, where the @style attribute declares a hook for the CSS to act on:

Content:
   <p sel:statement="news-item">The flooding was quite extensive.</p>
   <p>Many people were evacuated from their homes.</p>

XSLT:
1 <xsl:template match="p[@sel:statement='news-item']">
2   <xsl:copy><xsl:apply-templates /></xsl:copy>
3   <xsl:if test="dcn:cssmq-width('px') > 200">  
4   <p sel:expr="dcn:cssmq-width('px') > 200">
5     <object src="image1" sel:selid="artimg42"/>
6   </p>
7 </xsl:if>
8 </xsl:template match="p">

I've used sel:statement because sel:id is taken :) Also this template
can then be reused as needed.

2- HTML well-formedness. XSLT requires the source infoset to be
well-formed, so there may be some minor tidy up needed by the author. Of
course, that's a good thing!

I'll have a go at writing some tests and post to the group. Of course,
we can continue with DIAL which has great merits when aligned with the
IDEAL datatypes, but I can see that now becoming more of a CMS/device
aware engine language, with this XSLT approach providing a quick,
modular add-on to existing content markup. 

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 Tuesday, 11 December 2007 17:28:52 UTC