OpenOffice.org and web technologies, was: Re: XForms Editor Review

Stefano,

I think we shouldn't mix up an issue like 'how can we bring OpenOffice 
closer to the web?' with a very spcific issue like XForms support, which 
is in a quite early state.

I would thus like to take this topc to the dev@openoffice.org mailing 
list...

Stefano Debenedetti wrote:
> Lars Oppermann ha scritto:
>> 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)
> 
> It may be off-topic but it was a rhetorical remark much less than
> yours, I don't understand how can businesses and individuals who say:
> "let's NOT use the amazing value in best practices and applications
> under the web umbrella" be the first target of office productivity
> suites being developed now.

They are. XForms+XHTML is just a bad example to base this discussion on. 
The integration of XForms into OpenOffice.org poses significant 
challenges that are much more fundamental than XHTML+XForms export.

Bringing OpenOffice closer to the web is an important topic. And I very 
much invite you to share your ideas on that topic with the 
OpenOffice.org community...

I'll post another reply to your very XForms specific remark to www-forms.

All the best,
Lars

> What company doesn't have an intranet? Who doesn't have a blog? Are
> those your primary targets?
> 
> I thought your primary targets were companies and users who already
> have office productivity suites (and know how to use them) and have
> intranets and blogs (and love them) and who lose a lot of time
> everyday only because those things aren't integrated (and hate this).
> 
> 
> Of course I assume this must be related to why you lead the
> development of an office productivity suite and I don't, but that's
> not the point here, I speak as a user who thinks his use cases should
> be the first OO use cases, of course this opinion may spring out of a
> misleading and incomplete perception but yes I didn't assume you
> wanted to correct my perception.

I do not lead the development of an office productivity suite. I am 
responsible for the integration of XForms into OpenOffice.org.

I don't want to go into detail about the rest of your posting. The 
general idea that you were expressing was, that the tighter integration 
with web technologies is a significant growth path for OpenOffice.org. 
With that I wholeheartedly agree. Lets not confuse a very specific issue 
(i.e. XForms support) with this more abstract topic.

I don't want to go into further detail on the following.

> It just is my opinion, what I think is non-constructive is to dub it
> before having understood it. Of course nobody is deemed to even read
> it, I can avoid non-constructive rhetorical remarks by myself very
> quickly even when they are shoot at me in hideous ways via much more
> invasive medias than a mailing list. I think other people on the list
> can do the same without anybody "help" them by saying "I won't answer
> to this 'cause it's noise to people reading".
> 
> Unless you really think this is offtopic here, in which case I am
> happy to gracefully shut up on the topic.
> 
>>> 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.
> 
> Yes, I am sorry, I should have put it more clear in my mail that
> office apps can be productive even in a non-web world and that my
> negation of that is only related to my perception of no real future
> in that market as I perceive the needs of both businesses and
> individuals having fully embraced the web way since a few years.
> 
> I mean: when competing office productivity suites integrate
> seamlessly with the web, will OO be competitive?
> 
> Only in the non-web world?
> 
> Of course I don't assume you point the non-web world at me, I think
> the non-web forms world is less relevant to this list than discussing
> how far the XForms-based integration between web publishing and
> office document formats and productivity suites can go.
> 
> ciao ste
> 
> 
>

Received on Monday, 13 March 2006 15:06:15 UTC