RE: XULRunner Does XForms - XForms Calculator Demo Now Live

Hi Rafael,

> In our opinion, the problem is that in XForms we have a nice data-logic
> separation, but when you embed XForms in HTML, XUL, SVG, etc... we are
> mixing the presentation with the processing logic.
 
This whole area is very interesting, and a subject around which we have been
working for a couple of years. It sounds like you have reached the same
conclusion as us, in that we do not see XForms as a language to be embedded
into presentation-oriented languages like SVG. This is counter to
conventional wisdom, and there are a plenty of supporters of the idea that
XForms can live inside SVG. I wouldn't put XHTML into the same category
though, since it is not as presentational as people generally believe. And
this is even more the case for XHTML 2, which is returning XHTML to its
semantic roots.

This difference between languages like SVG on the one hand, and XHTML and
XForms on the other, has led us to broadly classify mark-up languages as
'abstract' languages and 'rendering' languages. In this model SVG is a
rendering language, whilst XForms captures abstract logic. XHTML is capable
of being both an 'abstract' and a 'rendering' language.

Some further comments on the idea of 'abstract' and 'rendering' languages
are on my blog, in the article entitled "SVG as a Stylesheet Language".
There's also a short video in the blog that shows an xf:trigger being
'skinned' with SVG, so that the 'hover' pseudo-class causes the text label
to 'fly' in. Try mixing things up that way with Flash!


> We are exoeriencing with a different approach in a PDA tool we developed
> -DataMovil-. What we are doing is assigning a "look" and a "layout" to the
> XForms controls in the same way as you use the "ref" attribute to link the
> logic and data parts of XForms. There are issues with presentation
> containers but XForms provides the "group" container that can be mapped to
> presentation containers in the same way. We are working into that.

Although we agree that we don't want to control the XForms 'look' by simply
dropping XForms into some rendering language, we have done this without
making any extensions to XForms. If I have understood what you are saying
correctly, then I would say that I don't think that adding an attribute to
controls is a good way to go.

Our route has been to use XBL--a binding language devised by the Mozilla
team, but now being standardised by a team comprising members of the W3C's
SVG and CSS Working Groups. We've created many applications that use SVG to
render XForms controls as digital and analogue clocks, thermometers, maps,
and so on. But in every single one of these cases we have kept the SVG in a
separate layer, maintaining the actual *logic* of the form as 'pure'
XHTML+XForms.

The connection between the XBL layer and the original form is established
via rules declared much like you would declare XSLT matching rules. This
keeps everything separate.

One important aspect of all of this is that the XBL modules define not just
a 'look' but functionality, too. You need this, since a calendar widget that
is bound to an xf:input that is in turn bound to a node of type xsd:date has
both behaviour and appearance.

Regards,

Mark


Mark Birbeck
CEO
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
http://www.formsPlayer.com/

Received on Sunday, 4 September 2005 09:59:04 UTC