W3C home > Mailing lists > Public > www-forms@w3.org > August 2001

XForms & XSLT (was: Re: NetScape/IE)

From: Sebastian Schnitzenbaumer <schnitz@mozquito.com>
Date: Sat, 4 Aug 2001 15:29:38 +0200
Message-ID: <D0F1529EE943B3449F755CA1A40887461116AC@winserver.windomain.mozquito.com>
To: "Bjoern Hoehrmann" <derhoermi@gmx.net>
Cc: <www-forms@w3.org>

you're right about the XSLT comparison in
the sense that Microsoft supported an early
draft in IE5. That definitely helped to boost
the awareness of XSLT in the market. However,
what I meant more was that in the end, today,
we see XSLT processors sitting on the server
and not on the client.

That this is natural since XSLT is server-side
in nature and forms are client-side in nature,
I'm not so sure about that, because:

XSLT is functionally something that every 
browser does internally anyway - the mapping 
between the initial parsetree and the internal
object model. Therefore we could have ended up
very well in a client-side XSLT deployment 
scenario technically - but in didn't happen. Why?

One reason why this didn't happen is because
XSLT has two major use cases:

* The transformation from one high-level,
semantic data XML grammar into another 
semantic data XML grammar.

* The transformation from one high-level,
semantic data XML grammar into a low-level
presentation layer XML grammar.

(BTW, discussion gets so much easier if you
divide XML functionally into XML-A, XML-P and XML-F:
- XML-A: Abstract XML for data exchange, etc.
- XML-P: Presentation XML - XHTML, SVG, XSL-FO, etc.
- XML-F: Functional XML - XSLT and XForms without the UI.)

The first XSLT use case, from XML-A to XML-A,
most naturally occurs where the data is being
held, which is most likely on the server.

But for the second use case, from XML-A to
XML-P, e.g. from an abstract XML data grammar
into XHTML or XSL-FO for rendering, which we see 
XSLT is being used for a lot, this could have well 
been done sitting inside the browser.

But still this second use case is successfully done
while the XSLT engine sits on the server. This is
what I mean with it took off successfully without
widely deployed browser support.

Now here comes the link to XForms. The first XSLT
use case is not what XForms is designed for, so
only the second XSLT use case is of interest to us.

Let's take a very concrete example where we see
both XSLT and XForms work together in harmony to
solve this second use case more efficiently:

In X-Smiles, my favorite pure XML browser, the
browser configuration file in being kept in a
XML data format customly designed for X-Smiles 
(XML-A). If you want to change the browser options
in X-Smiles, what happens is instead of having
a custom options dialog bound to the XML data 
format written in Java, X-Smiles uses both its
internal XSLT and XForms implementations in the 
browser to do the task in the main rendering 

If the user wants to change the browser settings,
the XML data format holding the current settings
is opened by the X-Smiles browser engine. This
XML-A grammar has an XSLT associated with it (XML-F).
The XSLT transforms the XML grammar into XSL-FO 
(XML-P). Without XForms, you would now see the
settings displayed in the browser, but you cannot 
"submit" the changes, ie. there is no back channel. 
This is because XSLT is always a 
one-way-transformation, e.g. from XML-A to XML-P
back not back again. 

XForms is bi-directional in nature, since you
can submit the same XML data instance associated 
with the XForm after the interactions with the 

What happens now in X-Smiles, is that the XSLT
transforms the XML-A via XSLT into XSL-FO with 
added XForms support. The XSL-FO in X-Smiles
uses the basic XForms concept of binding the
XForms UI controls in XSL-FO to an associated 
XML data instance via the XPath bindings and 
the ref attribute. The XSL-FO document the XSLT 
produces has the originating XML-A document 
associated with it via XForms.

Voila. Now the XSL-FO document presenting the
browser settings to the user has its UI controls
bound to the originating XML-A document. When the
user changes the settings, the copy of the
originating XML-A document loaded into the browser
gets changed. When the user hits submit, the 
updated XML-A document overwrites the existing
XML-A document on the hard drive. The circle is
complete, the settings have been changed.

So just as XSLT is the XML-F between XML-A and
XML-P in one direction, XForms is the XML-F back 
from XML-P to XML-A in the other direction.

Back to where we came from: If XForms is in some
cases a valuable addition to XSLT, or even in some
cases an alternative to XSLT, and if at the same
time XSLT is successful today performing this task
on the server, XForms can also be successful 
performing this task on the server and thus making
XForms useful this year.

How? Take the specific XForms implementation
Mozquito will provide this September with its 
XML WebAccess 2.0.

XML WebAccess implements XML-UI, a prequel to
XHTML 2.0, in the sense that this is the specific
combination of XForms with XHTML. As X-Smiles has
shown us, XForms can be used with many XML-P 
languages such as SVG, SMIL and XSL-FO. So XForms
really isn't only about XHTML. But the specific
markup language supported by XML WebAccess named 
XML-UI is indeed the long awaited XHTML + XForms.

XML WebAccess transcodes XML-UI documents 
on-the-fly on the web server into DHTML/JavaScript.
Just like XSLT can transcode from anything to
anything, but in many cases from anything into
something concrete presentational, XML WebAccess 
focusses on the concrete case of taking the specific 
XML-P called XML-UI into DHTML/JavaScript. How the 
XML-UI gets transcoded into DHTML/JavaScript is fixed 
in XML WebAccess, ie. you cannot change it and you 
don't have to. 

You don't have to because XML-UI as a language is 
very powerful since it is built upon XForms, and 
XForms is pretty powerful. The different combinations 
of XForms tags used in your custom XML-UI documents 
automatically change the XML-UI-to-JavaScript 
transformation schemes inside XML WebAccess. The
transformation schemes also automatically adjust 
depending on the client requesting the document, 
whether it is IE or Netscape in whatever version on 
whatever platform. The JavaScript output is powerful
enough the emulate the entire XForms functionality
on the client as if it was natively implemented by
the browser.

So with a server-side XForms implementation such as
XML WebAccess, you could do exactly what X-Smiles
does today completely on the server. The beauty is
that existing, deployed browsers can be used for
rendering/display without requiring end-users to 
install a plug-in or to use a different browser.

That's just one way of how XForms can be widely 
deployed this year and what lets XForms become more 
than just a Working Draft.

All the best,

- Sebastian

-----Ursprüngliche Nachricht-----
Von:	Bjoern Hoehrmann
Gesendet:	Sa 04.08.2001 04:33
An:	Sebastian Schnitzenbaumer
Cc:	www-forms@w3.org
Betreff:	Re: NetScape/IE

* Sebastian Schnitzenbaumer wrote:
>I agree that Microsoft and Netscape are
>unlikely to support XForms, but I very
>strongly disagree with the disruptive
>pseudo-quote "There is nothing called
>XForms, it's just a draft...".

I didn't mean to sound disruptive. What I wanted to say is, that XForms,
well, are just a current working draft, there is no normative
specification for it so it is in general unlikely, that you'll find any
support for them in current software releases, especially those focussed
on different targets. I _do_ think that XForms will be implemented by
Microsoft and Netscape, as I hope to see them used in XHTML 2.0, but I
see no chance for support, say, this year. I don't even think browser
support (or support by browser vendors) is needed for adoption of
XForms, there is a wide range of possible applications that gain great
advantages by using XForms and I even know of some experimental

I'm sorry if my mail implied something else.

>XSLT, for example, took off quite well 
>without Microsoft and Netscape ever 
>implementing it in the browser.

Microsoft had by the way very early support for XSLT in the Internet
Explorer; it was just an implementation of a working draft, but it
didn't take too long until Microsoft released a conforming XSLT 1.0
implementation. Comparing XSLT to XForms is however not really fair;
forms are an important part of XHTML and therfore of the browsers
while XML Transformations aren't.
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/
Received on Saturday, 4 August 2001 09:29:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:04 UTC