W3C home > Mailing lists > Public > public-appformats@w3.org > August 2006

Re: Decouple XBL2 From CSS

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Sat, 5 Aug 2006 17:21:36 +0100
Message-ID: <640dd5060608050921p5038281cy3a10e4a6960376c7@mail.gmail.com>
To: public-appformats@w3.org

Hi Bjoern,

> The argument you have to make is that implementers sooner or later will
> include support for using XPath with XBL2 in their implementation, and
> we therefore should determine now the steps to take to ensure that that
> will happen in the best possible way. Give us real world use cases that
> are unlikely to be realized using XBL2+Selectors but considerably more
> likely to be realized using XBL2+XPath. Give us real world tasks that
> are easy to accomplish using XAML/.NET 3.0 but difficult to accomplish
> using XBL2 as currently proposed because one relies heavily on XPath
> and the other does not support it at all. That browsers have some level
> of XPath support or that XPath is a Recommendation doesn't mean they
> will support XPath and XBL2 without any need, and they have a few good
> reasons not to.

I think this would be a very interesting exercise, but it's still
worth pointing out that the general request is not really for XBL to
'support' XPath selectors, but for the selection mechanism and the
language itself to be more distinct. That CSS selectors might be the
default selection mechanism is neither here nor there.

The reasoning behind this is that if done right, many different
applications could make use of XBL as an object definition language,
but they would be free to leverage the language in whatever way they
see fit.

Ian has already implied that efforts to create new versions of XBL
have floundered in the past because they have tried to do too much,
but in my view this is not true; sXBL, for example, did far too
*little* to make it really useful for applications, and I for one
didn't bother to get involved for that reason. In other words, having
in mind that XBL might be used in more places than an HTML browser
does not necessarily hurt the spec, particularly if the only feature
that people have requested so far is flexibility in binding.

Anyway, whether the answer is to separately produce a very small spec
that defines how to *select* object bindings, I don't know, but I'll
give here some examples of how we are using XBL in formsPlayer, our
XForms processor for IE, and how we locate the objects to be used, by
using XPath.

Many of the examples could use CSS to select the bindings, but some of
the later ones need additional features that allow us to do things
like test the capabilities of the platform we are running on. My
contention is not that CSS is *inherently* incapable of supporting
these kinds of tests in the future; I'm merely saying that XPath's
built-in extenibility mechanisms make it ideal for this kind of work

Anyway, on to the mark-up and some real, live examples from formsPlayer.


We have our own simple mark-up that uses XPath to determine which
objects should be bound to which nodes. To do simple things like bind
a widget to an XForms control that has a media type of 'image', we do

     match="xf:output[contains(@mediatype, 'image/')]/xf:pe--value"

The actual markup used in a document that would make use of such a
binding, would be this:

  <xf:output ref="a" mediatype="image/png">
    <xf:label>A picture:</xf:label>

This is not unlike using an <img> tag with attribute value templates:

  <img src="{a}" />

We use the same technique to attach objects that manage embedded video:


And so on.

Note that both of the binding rules cause an object to be attached to
the ::value part of the controls (which we've had to refer to via
xf:pe--value), and not the xf:output itself; this is because we don't
need to take over the entire control, just the actual bit that does
the rendering of an 'output' (or an input, a range, a select1, etc.).
We can leave the labels, hints, help, and so on to be managed by
further bound objects:

  <br:binding match="xf:hint" binding="xf-hint.xbl" />
  <br:binding match="xf:help" binding="xf-help.xbl" />

A control making use of a hint, looks like this:

  <xf:output ref="a" mediatype="image/png">
    <xf:label>A picture:</xf:label>
    <xf:hint>This is a picture of us on holiday</xf:hint>

As you can see, the rule doesn't care whether an xf:hint is a child of
an input, output, range, select1, or whatever...in fact it doesn't
even care if it's part of a control from another language. This gives
us a high level of re-use, and by binding to the 'most specific' part
of a control, we can also mix things up--we could use a spoken hint
with a range control that is an SVG thermometer:

  <xf:range ref="a" class="thermometer">
    <xf:label>A temperature:</xf:label>
    <xf:hint style="speech: normal;">
      The temperature is
      <xf:output value="if(. &lt; 32, 'not', '')" />

If a binding is not available, then in formsPlayer default bindings
are applied, so in this example we would get an ordinary range control
instead of an SVG one, and the hint would just be test. This is
achieved simply by having a further set of bindings, with the most
specific one winning.


Sometimes we want to use a set of binding objects only if the client
application supports certain functionality. In formsPlayer we can
currently test for installed features using 'feature strings', so to
make use of a set of SVG widgets only if the client application
actually supports SVG, we do this:

  <br:bindings feature="org.w3c.svg" version="1.0">

In formsPlayer the @feature and @version attributes simply map to
references to our version of the DOM 3 Implementation Registry. We use
this to manage the creation of all objects in formsPlayer, and it's
very easy to add new ones. By including them in our DOM3Impl file,
their existence will 'show up' and be available to binding rules like
those given above. The following exert shows how plug-ins for MathML,
SVG and XForms are defined:

    <feature name="org.w3c.dom.mathml" version="1.0">
      <!-- Design Science MathML Viewer -->
    <feature name="org.w3c.svg" version="1.0">
      <!-- Adobe SVG Viewer -->
    <feature name="org.w3c.svg" version="1.0">
      <!-- Corel SVG Viewer -->
    <feature name="org.w3c.xforms.dom" version="1.0">
      <!-- formsPlayer 1.n.n.nnnn -->

To illustrate the power of this, let's go back to the video example I
gave earlier:


A piece of mark-up that makes use of this binding object might be:

  <xf:output ref="a" mediatype="application/x-mplayer2">
    <xf:label>A video:</xf:label>
    <xf:hint>This is a video of us on holiday</xf:hint>

The problem with this is that we've now made our form use a very
specific bit of mark-up that requires that a particular plug-in has
been installed. Ideally we want our mark-up to look more like this:

  <xf:output ref="a" mediatype="image/video">
    <xf:label>A video:</xf:label>
    <xf:hint>This is a video of us on holiday</xf:hint>

In other words, we want something generic for the @mediatype
attribute. If we did that, we could hide the decision about which
particular video player plug-in to use inside our bindings file, like

  <br:bindings feature="com.microsoft.mediaplayer">
  <br:bindings feature="com.real.realplayer">

(The server would still have to do some work...but you can't have everything!)

With these binding rules we will get a different video player widget
depending on the application's capabilities, without ever needing to
change the web application's mark-up. We could even define a default
'video widget' that tells the user that they don't have a video
capability installed, and provides some links.

And making the binding language aware of the applications'
capabilities means that what we can do for video we can do for
anything else; it's just as easy to add entries that detect
text-to-speech, voice input, audio playback and recording, digital
pens, and so on.


One final thing to point out is that XPath is set to be used to
provide more dynamic kinds of information, and this is largely because
it has a simple function extension mechanism. This means that XPath
gives us a way to extend the capabilities of the XBL selection
language without having to wait for the slow processes that have come
to charecterise the CSS standards work.

For example, there is a proposal to provide access to delivery context
information using XPath, according to 'Delivery Context: Interfaces
(DCI) Accessing Static and Dynamic Properties':


An example of using a function to retrieve the current battery level is here:


And it doesn't take a great leap in imagination to see how this
information could be used to select an XBL-defined component:

     match="xf:output[dcn:search('battery') &lt; 20]/xf:pe--value"

Driving a widget from the battery level of a computer is somewhat
contrived, and I only use this since it's an example from the working
draft, but it does illustrate the point. Other capabilities that the
spec would support range from the bacground noise level to the GPS
position. A more realistic scenario might be, therefore, to render
different widgets depending on the background noise level, allowing a
phone user to see a text version of what the person they are speaking
to is saying, and providing a text input facility for the phone user.


Finally, some words on how we locate the binding rules. To make use of
the binding rules we obviously need to load them into the application
that wishes to use them, and in formsPlayer we do this by locating a
<link> element in the web application document, which has @rel set to
"bindings". For example:

  <html ...>
      <link rel="bindings" href="chrome/my-bindings.xml" />
      <xf:output ref="a" mediatype="image/png">
        <xf:label>A picture:</xf:label>

Note that the default 'scenario' is to load the binding rules and then
apply them at run-time to the web application, but these rules could
be used in some kind of server-side or pre-processing step, perhaps
using an XSLT processor. The bindings could be applied at a stage
before delivery of the document, in order to add suitable
functionality for voice, phones, desktop browsers, and so on, even if
the target client does not support XBL.



Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
Received on Saturday, 5 August 2006 16:21:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:05 UTC