W3C home > Mailing lists > Public > public-uwa@w3.org > December 2007

RE: URIs, content adaptation, DISelect and XSLT

From: Dave Raggett <dsr@w3.org>
Date: Wed, 12 Dec 2007 15:42:19 +0000 (GMT)
To: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
Cc: Max Froumentin <max@lapin-bleu.net>, "Smith, Kevin, VF-Group" <Kevin.Smith@vodafone.com>, public-uwa@w3.org
Message-ID: <alpine.DEB.0.99.0712121514410.11214@ivy>

On Wed, 12 Dec 2007, Rotan Hanrahan wrote:

> Splitting text can be trivial, or complex, depending on the nature of
> the text. Where there is much contextual dependency within the text,
> splitting it can cause misinterpretation of the content by the end user.
> Related text needs to be kept together, the order of consumption needs
> to be maintained. Internal textual references need to be avoided (e.g.
> "... as mentioned on the previous page ...") because the page flow has
> been augmented by the internal pagination. Where forms are involved,
> splitting of the forms needs to be done in a manner that does not break
> the data model, nor separate closely bound controls (e.g. a field and
> its label). So, while at first, splitting may seem trivial, I can
> confirm from experience that it is not.

That's a nice account of the challenges and why it seems like a good 
idea for the author to indicate good places for boundaries. 
Computers lack common sense, and however good the heuristics, there 
well always be a time when they fail. Getting authors to think about 
pagination will also help to reduce problems like "see above" or "as 
mentioned on the previous page". Do the mobile web best practices 
say anything about how authors indicate possible pagination 
boundaries? If not then perhaps this is something worth considering.

Splitting forms and preserving the original data model for 
subsequent server-side processing is an interesting problem. This is 
where life would be easier if the application is modelled in such a 
way that allows you to generate both client and server components 
from the models.

The purpose of starting this thread was to see whether XSLT is 
valuable for content selection/adaptation as opposed to embedding 
DISelect markup, and whether there is a need for additional XPath 
functions to assist with pagination.

XSLT could be used in a number of ways, e.g.

   - to transform a separate markup document into the adapted content
   - to combine markup fragments from a content management system
   - to select between markup fragments embeded within the XSLT

You could combine XSLT with scripted functions when it is otherwise 
too painful to express the desired behavior directly in XSLT. 
Developers may need to write additional client and server-side 
scripts when forms are split across multiple pages. There is no 
magic!

> PS I would prefer that we do not use the term "chunk" as this is 
> already an established term within the HTTP specifications, as in 
> the "chunked transfer encoding", which has nothing to do with 
> automated pagination.

Agreed, perhaps sub-page or some such term would be better.


  Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
Received on Wednesday, 12 December 2007 15:41:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 April 2009 12:37:21 GMT