Re: [office-comment] Interface META-Functions

[Thomas Zander <zander@kde.org>]

On Sunday 10 June 2007 16:02:22 Leonard Mada wrote:
> Hi Thomas,
>
> Thomas Zander wrote:
> > On Saturday 09 June 2007 13:31:52 Leonard Mada wrote:
> >> However, it is difficult to implement every function inside the
> >> spreadsheet application, especially as complex functions are not
> >> trivial to implement.
> >>
> >> This is even NOT necessary, because often advanced open source
> >> programs do exist which fill the gap.
> >>
> >> However, what is lacking is *a standardized way * to communicate to
> >> these external programs.
> >
> > Hmm, i was under the impression that ODF was _the_ way to communicate
> > to these external programs.
> > Send the data in an (small) spread sheet file to the external
> > application and get the results back in a similar file.

> I envision three unsurmountable problems with this approach:
> [There existed 'csv' before, so the problem is NOT new! I still usually
> import spreadsheet files through an intermediary csv file in R and then
> make the statistical analysis in R. Though this is time consuming, and
> IF I detect an error and need to correct the initial spreadsheet, this
> becomes a nuisance, too.]
>
>  1.) you can NOT force every program developer to support ODF,
>       or to support it fully and completely, e.g.:
>           - it MUST support ALL functions
[]

Oh, now I think we are talking about several different issues at the same 
time.
Lets specify this and not confuse ourselves :)

In order to automate the process you described above where you use CSV 
files we should not only use csv, but we should allow the format to be 
richer than csv allows.
So, if you want to select 2 columns in your spreadsheet that you need to 
statically Analise I forsee the following automated scenario.
1) you select the cells.
2) you press 'copy' which creates a simple xml file on the clipboard, one 
that is valid ODF, but surely will include all the calculated values of 
the cells that are formulas. (which is optional). 
3) you either go to another application or you use some automation or form 
to then paste the ODF fragment in your external app, let it do its work 
and then generate a new ODF fragment on the clipboard.
4) you either paste the results over the previous selection or do it 
somewhere else. Entirely depending on the situation.

Naturally, this whole sequence of events can again be automated, like we 
do now for charts that are upgraded whenever a value is changed in the 
spreadsheet.


>  2.) you will need to work (simultaneously) in multiple programs

While I am aware that in Windows this is "not done" this is something in 
the Unix world (KDE specifically) that is done all the time. And the user 
tends to not even be aware of the context change, typically because the 
integration is very well done.
So, this is certainly not a problem for the ODF list, this is more a new 
challenge for the application developers.

>  3.) updating the cells (after one cell has been corrected) will be a
> catastrophy;
>       - it is even impossible to implement  a mechanism which will tell
> the user that
>        some cells are NOT updated, as the spreadsheet program can NOT
> know how those cells were computed using the external application

This is not true, and one of the main reasons I mentioned ODF. ODF has 
change-set support. Which means that if you change one part you only sent 
that one part in a separate file to the other application which will then 
be able to merge it with the previous document it had.

> Of course, IF the spreadsheet program acts as a server that presents
> the data to the external applications, some of these problems are
> solved, BUT then this solution is closer to my proposal, and there
> still remain some problems discussed especially at points 1.) and 2.).

Well, I have been working with a lot of people on solving quite similar 
problems and we have concluded that, actually, making a wide range of 
applications aware of ODF and be able to read it and write it will allow 
a whole host of new features and possibilities.
Which is specifically why I think adding new stuff in ODF like you 
suggested is not the right way to go. It just makes the applications even 
more monolithic which is clearly not what the user wants (ask any HCI 
expert for that one ;)

> Hope this clarifies some of the problems.

I understand the problems you perceive, and I am aware they are hard to 
tackle. The issue here is thus more the question of do we want to 
continue adding specific features to each and every application we want 
to talk to, or do we want to leverage ODF as the communications medium 
and work from there.
-- 
Thomas Zander

PGP signature