Document adaptation using DIAL and DISelect

[Cameron McCormack-4]

Hi DIWG.

I read with interest the Content Selection for Device Independence and
Device Independent Authoring Language drafts.  The ability to adapt
documents on the web to the viewing context is an important one, and one
that we[1] are interested in.  While our work[2,3] is principally
regarding diagram adaptation, the techniques we have been investigating
could well be applied to XHTML documents with a little modification.

In fact, Constraint SVG (CSVG)[4,5], an extension of SVG we developed
that uses XPath expressions for attribute values, seems to be somewhat
similar to DISelect.  Notable similarities include:

  ▪ The use of XPath expressions to give values to attributes.

  ▪ XPath functions that expose available display space.

  ▪ Variable declarations within the document.

The main differences in CSVG are:

  ▪ Adaptation occurs within the document, and the elements and
    attributes that effect the adaptation are still present when
    the document is running.

  ▪ XSLT can be used to define reusable components, as in the style of
    XBL.

  ▪ Attribute values are typically given as SMIL animation elements,
    rather than Attribute Value Templates (although AVTs may be used in
    XSLT templates).

  ▪ For simple cases, elements are excluded from processing just by
    setting their ‘display’ attribute to ‘none’ with an expression
    (although elements can be omitted properly as with DISelect if
    an XSLT template is used).

  ▪ Insertion of text content in the document must be done with
    ‘xsl:text’ in a template.

  ▪ The XPath expression syntax used is an extended form of XPath 1.0
    that allows not only arbitrary location paths, but also typed
    access to SVG element attributes.

  ▪ The bounding box of elements may be retrieved using the c:bbox()
    XPath extension function.

  ▪ XPath expressions may perform operations on fundamental SVG types,
    such as points, rects and matrices.

  ▪ Variables may be redefined in terms of the previous value of the
    variable, which is useful for iteratively generated template shadow
    trees.

  ▪ Automatic propagation of values between dependent XPath expressions.

While the decision to include or exclude various elements of a document
is a useful part of the adaptation process, as can be done with the
‘sel:if’, ‘sel:select’, ‘sel:when’ and ‘sel:otherwise’ elements, more
flexible layout is required that is not possible just with DISelect plus
CSS.  As an example, consider an XHTML document layed out as follows
(view in a monospaced font):

  +--------------------------------+
  |                                |
  | par1 par1 par1                 |
  | par1 par1 par1                 |
  |                 par2 par2 par2 |
  |                 par2 par2 par2 |
  |                                |
  +--------------------------------+

The two paragraphs of text have the same width (50% of the containing
block), but with the additional constraint that the blocks containing
the two paragraphs must have the same height.  The XHTML might look like
this:

  <div id="d1">
    <p id="p1">par1 par1 …</p>
  </div>
  <div id="d2">
    <p id="p2”>par2 par2 …</p>
  </div>

The widths and horizontal positioning can be set with:

  #d1, #d2 { width: 50%; }
  #d1 { margin-right: auto; }
  #d2 { margin-left: auto; }
   
But for the containing div heights, we need to know the actual
heights of p1 and p2.  In CSVG, we have the bbox function that computes
the bounding box of a given element.  If analagous functions to get the
CSS box dimensions existed in DISelect, the maximum of the two paragraph
heights could be computed to give the div heights.  For example:

  <sel:variable name="p1h" value="css-box-height(id('p1'))"/>
  <sel:variable name="p2h" value="css-box-height(id('p2'))"/>
  <style>
    #d1, #d2 {
      height: <sel:value expr="max($p1h, $p2h)"/>;
    }
  </style>

Being able to get the CSS box dimensions of elements can allow for much
more powerful layout adaptation than is possible with DISelect plus CSS
as it stands.  XHTML does not require as much support for layout
adaptation than SVG, because of the CSS box model, but more than what is
currently specified in DISelect is needed.

Another aspect of CSVG that allows powerful client-side adaptation is
the inclusion of the adaptation specifications in the document being
processed by the UA.  Since the processing model of DISelect is a
transformation of a source infoset to a result infoset, where it is this
result infoset that is given to the (for example) XHTML UA for
processing, there is no chance to control the adaptation from within the
document.  This is especially important for controlling adaptation in
response to user interaction.  Whereas in CSVG, event handlers may
modify the expressions used in the document to specify the adaptation
and have the changes be reflected in the display immediately, DISelect
does not provide access to the source infoset that would allow such
modification.

I am quite interested in what will go in the currently empty “Applying
Layout” section of DIAL, as there is certainly scope here to provide
more powerful layout techniques on top of DISelect.  What is planned for
this?  I notice also that the WG’s charter mentions a work item “Layout
for Device Independence Version 1.0”.  Has any progress on this been
made?

Also, I would like to know if adaptation of diagrams will be considered
somewhere in the context of the Device Independent Working Group, as
support for such adaptation, as we have found, is more important than
XHTML layout adaptation—XHTML has CSS, which can do simple layout,
whereas SVG cannot have layouts specified declaratively for anything
more complex than viewport relative percentages.  The types of
adaptation that are needed for diagrams[6] cannot be currently achieved
using a declarative syntax.

Thanks,

Cameron

[1] Adaptive Diagrams Group, part of: http://www.csse.monash.edu.au/research/OandCS/
[2] http://www.csse.monash.edu.au/research/OandCS/research/researchinterests/diagramlayout.html
[3] http://www.csse.monash.edu.au/~marriott/MarMeyStu04.pdf
[4] http://www.svgconference.com/SVG_2004/2004/papers/ConstraintSVG/
[5] http://www.csse.monash.edu.au/~clm/csvg/
[6] Forthcoming technical report,
    http://www.csse.monash.edu.au/~clm/2006/05/adaptation-types.pdf

--
Cameron McCormack, http://mcc.id.au/
        xmpp:heycam@...  ▪  ICQ 26955922  ▪  MSN cam@...

[Max Froumentin]

Hi Cameron,

Thanks for your comments. Let me try and answer your questions
(everything below my own opinion, not the WG's).

DISelect is open in terms of XPath access functions: we're defining a
few, based on CSS media queries, but others can be added, which can
return more complex layout information, like the css-box-height
function you describe. However, note that the kind of information that
those functions return must be able to be sent to whatever adaptation
engine will process DISelect expressions. For instance, an adaptation
engine that sits between a web server and your mobile phone (on one of
your mobile phone provider's gateways, say) may get values out of the
cssmq-width function from delivery-context mechanisms such as CC/PP,
or WURFL. It's less obvious how that can happen with layout functions.

Moreover, DIAL is an authoring language, and so is DISelect
markup. The reason why DISelect is designed to be embedded in the
document, and not an extension to CSS, is that it's all about
selecting content, not style. sel:select will be used for selecting
between different versions of a text (long or short, typically), but
not to change the colour of a page. Of course you can put a
<sel:select> around a <style>, but (again, in my opinion) that's going
too far and embeds styling and presentation like it's 1995.

If the language DISelect is embedded in is SVG, then things are
different, however. It's going further than the DI working group
envisaged, but since SVG is already presentation and content
(arguably), one could imagine DISelect markup be used, along with new
XPath functions.  I don't believe the WG has ever considered that use
case. At least it hasn't discussed it for the last year and a half. We
will keep this use case in mind though, but I doubt we would be adding
more features to do things as complex as constrained SVG.  But when we
discuss the Layout section of DIAL, I'm sure we'll recall your email
and will consider your ideas.

Cheers,

Max.