OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [oic] Interoperability challenges


Hi Andreas,

thanks for the interesting scenario, I certainly take the challenge..

First let us agree on the requirments. What does the user expect from the application in the given scenario.
From the description of https://bugs.freedesktop.org/show_bug.cgi?id=40262
I can come up with four distinct user scenarios to paste the cells of the cell-range into the (new) document:
  1. Pasting to a part where no table exists, and no table is allowed
  2. Pasting to a part where no table exists, and a table is allowed
  3. Pasting to a part where a table exists, and the cell-range fits into the existing table
  4. Pasting to a part where a table exists, and the cell-range exceeds the existing table
From my user perspective I would expect the above scenarios should be result into the following:
  1. It should not be possible to create invalid ODF, therefore paste should not be allowed at some places
  2. A new table should be created. The new table would only consist from the giving cell-range
  3. The existing table data should be overwritten from the data in the clipboard. (Cursor is upper left corner of new content.)
  4. The none intersecting part should expand the existing table, while the intersecting part should be overwritten. (Cursor is upper left corner of new content.)
If we agree on above requirments and user expectations, we can start to discuss how to solve it.
(Not mentioning that the existing solution is not standardized at all).

From above scenarios, it seems that our current solution to use an ODF XML file is suboptimal as we require three different ODF XML dependent on the destination.
Unfortunately the destination do not known during "copy" time what XML is required. Do we have to provide three XML parts, one for each possibility?
Or does the receiving application have to deal with one XML and transforms it to the other two?
We should keep in mind that in contrary to HTML, the run-time model of an ODF application is not necessary similar to the file format.

Incidentally I have provided a suggestion of a comprise on the two collaboration proposals to the collaboration sub-comittee last Saturday, which could be used to the above challenge. In short having XML in the clipboard, making it necessary for the ODF application to deal with XML anytime during run-time. A different solution would be only taking the changes (the creation/modification to receive the clipboard content) into account.

Please fetch a coffee and read the following submissions:
http://lists.oasis-open.org/archives/office-collab/201108/msg00023.html
http://lists.oasis-open.org/archives/office-collab/201108/msg00024.html
http://lists.oasis-open.org/archives/office-collab/201108/msg00025.html

Especially the first mail is not short. But the size results not from fast writing, instead from the aggregation of work of months.

Best regards,
Svante


On 24.08.2011 07:19, Andreas J. Guelzow wrote:
1314163166.5616.4.camel@kirkman" type="cite">
For an example of an interoperability challenge please see
https://bugs.freedesktop.org/show_bug.cgi?id=40262

I have raised the same issue on #odfplugfest on freenode and on the ODF
Plugfest mailinglist <plugtest@opendocsociety.org>. I did not get any
response yet on these two media (not counting an inquiry by Michiel
whether I had a response). 

Of course these non-responses are more desirable than the response on
the bug report.

Andreas



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]