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


The last time I tried anything like this, Edit | Paste Special ... offered more cases for the user.  Is that not still the case?

I think the key thing is that the special identifiers for these clip-board formats and the formats themselves are not documented, so without knowing what they are, the paste function doesn't have a means to adjust to the circumstances.  For example, pasting into a selection can be very different than pasting into a point in the document.  (The same thing applies for the "OLE" and DDE usages.)

I also think that creating a bug on the issue is a good idea.  But it is probably valuable to also take the issue to the developer list at LibreOffice also, to help the issue be understood and to also create conversation around the interoperability concerns.  My experience is that there are sympathetic folks there.  

I would also continue to develop the matter on the Plugfest list and also here to the extent it is possible to create an actionable advisory and perhaps test cases.

This conversation can also be bridged to the Apache OpenOffice podling when that project is prepared to take on such matters as well, not to mention independent implementations and interop with products having different native models (e.g., Microsoft Office).

 - Dennis

-----Original Message-----
From: Svante Schubert [mailto:Svante.Schubert@oracle.com] 
Sent: Wednesday, August 24, 2011 01:18
To: oic@lists.oasis-open.org
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: 

	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> <mailto: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]