- From: Lars Oppermann <Lars.Oppermann@Sun.COM>
- Date: Mon, 13 Mar 2006 13:10:19 +0100
- To: Stefano Debenedetti <ste@demaledetti.net>
- Cc: www-forms@w3.org
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