W3C home > Mailing lists > Public > www-forms@w3.org > September 2000

Re: AW: Using XSL-T to convert XForm to HTML: Impossible?

From: Simon Brooke <simon@weft.co.uk>
Date: Fri, 22 Sep 2000 19:59:30 +0100
To: "Josef Dietl" <josef@mozquito.com>, <www-forms@w3.org>
Message-Id: <00092219593000.15623@gododdin.internal.jasmine.org.uk>
On Fri, 22 Sep 2000, Josef Dietl wrote:
> Hello Simon,
>
> I'm glad to hear this type of input because it helps make XForms a
> better specification. Let me recap what you are saying, just to make
> sure I understand you correctly:
> You say that the separation of model and instance makes it impossible to
> create a pre-populated HTML form from an XForm document in one XSL-T
> transformation. Right?

That's my belief, yes. I don't claim to be an XSL-T guru, although I've been 
using it pretty intensively for a year now; I don't see how in one transofrm 
you can simultaneously walk down two branches of the document tree in 
parallel and integrate the results.

What you could do is have an xsl-t transform which you ran against the XForm 
document and produced a seconnd xsl-t transform which integrated the model; 
this second xsl-t transform could then be run against the XForm document in a 
second pass to integrate the instance data. The problem with this is that 
when you're populating a form with instance data you're almost always doing 
it as part of a dialogue with a user, and this makes the time-cost a 
significant issue. Of course if you do this with DOM objects in memory it is 
significantly less bad, but if you are having to write out to a stream and 
then parse in again to do your second transform then the computational cost 
is going to be just horrid.

> Generally speaking, that's not as it should be. As far as I can tell, it
> really is a difficulty related to the mere _concept_ of separation of
> model and instance. You not doubting the usefulness of this separation
> raises the question: Is it a design bug in XForm or a weakness in XSL-T?
> Given the history of XSL-T (originally a presentational language, in
> tandem with XSL-FO), it looks like a bad choice for the task at hand.
> Admittedly there's not much choice around.

I think more than anything else it's a consequence of the development of HTML 
forms - a quick hack to get simple things working that proved so successful 
it's now used for things which are more sophisticated than it's designers 
ever imagined. The separation of model and instance must be a good thing; if 
it had been done in HTML2 we would not have this problem now.

> So, I'd rather adress the need for a more powerful transformation
> language than change the design of XForm. What do you think?

Don't knock xsl-t -- it's an impressive piece of software with powerful 
capabilities. The problem is that it's essentially a recursive 
pattern-matcher, much like a resolution theorem prover. It will traverse any 
arbitrary tree, but one branch at a time -- and the separation of model from 
instance make this impossible.


-- 
Simon Brooke, Technical Director, Weft Technology Ltd -- 
http://www.weft.co.uk/

	the weft is not just what binds the web: it is what makes it a web
Received on Friday, 22 September 2000 15:00:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:48 GMT