On 18.03.2012 23:53, André Rebentisch wrote:
My
apologies, I'll have an important meeting tomorrow but still let
me ask a stupid question:
Am 18.03.2012 22:55, schrieb Svante Schubert:
2. It does not work out, if two ODF
applications declare to support
change-tracking, but define different functionality. There
should be
one minimum set being defined for a minimum of
interoperability.
Like implement the minimum of this feature or leave it.
What exactly do you have in mind with regard to change tracking:
* app-time "undo support" --> application driven
or
* saved revisions (incl auto-save) -> document driven
?
Collaboration events, undo, change-tracking are all of the same
kind, see
http://lists.oasis-open.org/archives/office-collab/201107/msg00017.html
Support for the former can be documented via n revisions in a
strict "document driven" way that would be 100% interoperable.
Each revision is a diff to the xml files etc. We know that
XMLdiff solutions exist cmp e.g
http://msdn.microsoft.com/en-us/library/aa302294.aspx
but since it is no beauty contest ordinary diff functionality
would do.
If we use an ODF XML base approach instead of using an abstraction
layer (as operations on high level ODF components), we will get an
interoperability problem in the future when browsers want to
collaborate with ancient ODF applications. For collaboration we need
in the end a lingua franca to communicate on the same level of
understanding. The obvious choice for this level are the well known
entities as paragraph, heading, section, table, etc.
An advantage of a "content agnostic" stricly document driven
approach
is a high degree of interoperability.
I agree, although on a higher abstraction level than the ODF XML.
For instance, the browser is HTML centric and instead of mapping all
ODF to HTML and back it is much more straight forward to have a JS
library taking those events and mapping them to adapt directly the
model of the application. Much leaner and works as well on small
devices.
For list of examples for the change-tracking I had in mind, please
take a look at http://www.oasis-open.org/committees/document.php?document_id=45463&wg_abbrev=office-collab
For more app-time related changes you may want to model a
"document processing machine" and define a set of API
functionalities. App-time changes would usually also extend to
app-specific issues (e.g. set the paintbrush colour to green)
while document driven changes would only extend those changes
which alter the document ("add red rectangle")
We are currently focusing on document changes not on application
commands. For instance, application could react/behave different
with similar user interaction. Best example is a user text selection
starting within the mid a heading and ending in the mid following
paragraph. If the user presses delete it will result in Libre|OOo to
delete the text and merge heading and paragraph, while in MS Office
only the text is delete and there are still two different entities
of heading and paragraph. No problem for
change-tracking/collaboration as both scenarios are mappable to
commands - in MS Office the user have to trigger the merge
explicitly.
BTW this use case, I had in the back of my mind, when I added the
example on slide 13 of the MCT presentation, see
http://www.oasis-open.org/apps/org/workgroup/office-collab/download.php/45161/latest
Best,
Svante
---
A
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
