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 [email protected] 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
