Re: XForms Editor Review

Stefano Debenedetti wrote:
> I fail to see how can an office application claim to be a
> "productivity" application if it cannot export to the web. (And I
> don't even condider the possibility that an office application
> exports in HTML instead than XHTML).
> 

I take that this is a rhetorical remark, and that you do not expect me 
to explain to you the productive tasks that can be handled with an 
application like OpenOffice.org without it being able to export 
XForms+XHTML. This would be off-topic for this list anyway.
(BTW, OOo includes an XSLT based XHTML export filter)

> OO must do that to be an office productivity application.
> 
> Unless its agenda is really "introduce rich declarative XML based
> forms into the world fullstop".

XML based forms have already been introduced to the world. They are 
quite new in the domain of office productivity apps. Also the MVC based 
approach to forms is new in that realm, since traditionally those forms 
had an implicit model, mostly defined by the form layout, and custom 
coded logic, implemented mostly by scripts.

The concepts introduced by XForms are very valuable even outside a web 
browser. Documents produced with the current XForms implementation 
include all the information that is required to translate them to 
XForms+XHTML. There is nothing preventing you from writing a filter, 
that outputs this particular combination. I bet a lot of other people 
would be interested in that too.

XForms goes to great lengths in establishing independence of the host 
language. Thus, the claim of an implementation being unusable because of 
the fact that it is not exporting XHTML+XForms can only be bogus. It 
might be unusable for your particular intend. I am sorry about that - 
others are using it in a quite productive manner though.

/lars

Received on Monday, 13 March 2006 12:10:30 UTC