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