[
https://issues.apache.org/jira/browse/ODFTOOLKIT-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Svante Schubert updated ODFTOOLKIT-441:
---------------------------------------
Description:
ABSTRACT
This feature will improve document collaboration by focusing on document
changes.
It simplifies collaboration by exchanging only the document delta, thus
fostering efficiency and meaningfulness.
SCENARIO
In the future when loading an ODF text document into this library, the document
is being mapped to a list of high level user changes. This sequence of changes
is equal to a batch of user actions, creating an equal document from the top to
the bottom. 3rd party software such as web editors meant to receive this list
(in JSON) to create their document representation. Similar they should gather
their user changes as a similar change sequence and return them. This feature
will enable the library to merge new changes back into the document.
Changes have the advantage to abstract from design details of document
serialization and will remain in general on the logical level known by common
users.
In addition, changes are atomic. They bundle the manipulation of sometimes
scattered feature data into a single change step.
Atomicity allows two adjacent changes within the change list to be switched
without requiring further context, easing the alteration of work history, such
as normalization.
To allow compatibility of changes among office applications from the beginning
and accelerate their development, there is an ongoing effort of standardization
changes based on the ODF XML file format.
BACKGROUND
Prior to the upcoming OASIS ODF 1.3 version only the complete ODF document had
been standardized. (For instance, its zipped XML files, the manifest,
signature, encryption and RDF metadata).
Therefore, the only interoperable way to synchronize changes between
collaborating office users was the exchange of the complete document using
change-tracking. Change-Tracking is always stored within the content, requiring
to process the complete document content.
This does not scale with multiple users working at the same time on a document.
For instance, real-time collaboration requires instantaneous user feedback.
Exchanging the complete documents on every synchronization among participants
is not feasible.
Similar it is in general less transparent and less safe to receive from a 3rd
party a document including their changes in opposite to exchanging the changes
alone.
To alter this disadvantageous situation and be able to exchange predefined
deltas of an office document, ODF changes are currently being standardized in
the ODF Advanced Document Collaboration subcommittee of OASIS. An ODF change is
a typical user change on "logical document parts", e.g. paragraph, image or
text character. There are three change types: add, modify or delete. Every high
level ODF change is going to be mapped by the specification to the manipulation
of one or more XML nodes within the document. The abstraction from XML changes
by these typed operation is necessary as most ODF application are not aware of
ODF XML during the runtime. In contrast to HTML, ODF does not require a common
model such as DOM.
The serialization of changes will be offered in JSON by this feature as the
common use case is to have the ODF Toolkit in the back end, while a web based
editor receives such changes and renders the document.
In addition to that, the ODF Toolkit will be capable to receive user changes
made by a client to the document and merge them into the document by applying
one change after the other on its internal ODF XML DOM model.
was:
ABSTRACT
This feature will improve document collaboration by focusing on document
changes.
It simplifies collaboration by exchanging only the document delta, thus
fostering efficiency and meaningfulness.
SCENARIO
In the future when loading an ODF text document into this library, the document
is being mapped to a list of high level user changes. This sequence of changes
is equal to a batch of user actions, creating an equal document from the top to
the bottom. 3rd party software such as web editors meant to receive this list
(in JSON) to create their document representation. Similar they should gather
their user changes as a similar change sequence and return them. This feature
will enable the library to merge new changes back into the document.
Changes have the advantage to abstract from design details of document
serialization and will remain in general on the logical level known by common
users.
In addition, changes are atomic. They bundle the manipulation of sometimes
scattered feature data into a single change step.
Atomicity allows two adjacent changes within the change list to be switched
without requiring further context, easing the alteration of work history, such
as normalization.
To allow compatibility of changes among office applications from the beginning
and accelerate their development, there is an ongoing effort of standardization
changes based on the ODF XML file format.
BACKGROUND
Prior to the upcoming OASIS ODF 1.3 version only the complete ODF document had
been standardized. (For instance, its zipped XML files, the manifest,
signature, encryption and RDF metadata).
Therefore, the only interoperable way to synchronize changes between
collaborating office users was the exchange of the complete document using
change-tracking. Change-Tracking is always stored within the content, requiring
to process the complete document content.
This does not scale with multiple users working at the same time on a document.
For instance, real-time collaboration requires instantaneous user feedback.
Exchanging the complete documents on every synchronization among participants
is not feasible.
Similar it is in general less transparent and less safe to receive from a 3rd
party a document including their changes in opposite to exchanging the changes
alone.
To alter this disadvantageous situation and be able to exchange predefined
deltas of an office document, ODF changes are currently being standardized in
the ODF Advanced Document Collaboration subcommittee of OASIS. An ODF change is
a typical user change on "logical document parts", e.g. paragraph, image or
text character. There are three change types in general to add, modify or
delete. Every high level ODF change is going to be mapped by the specification
to the manipulation of one or more XML nodes within the document. The
abstraction from XML changes by these typed operation is necessary as most ODF
application are not aware of ODF XML during the runtime. In contrast to HTML,
ODF does not require a common model such as DOM.
The serialization of changes will be offered in JSON by this feature as the
common use case is to have the ODF Toolkit in the back end, while a web based
editor receives such changes and renders the document.
In addition to that, the ODF Toolkit will be capable to receive user changes
made by a client to the document and merge them into the document by applying
one change after the other on its internal ODF XML DOM model.
> Improving Document Collaboration
> --------------------------------
>
> Key: ODFTOOLKIT-441
> URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-441
> Project: ODF Toolkit
> Issue Type: New Feature
> Components: odfdom
> Reporter: Svante Schubert
> Assignee: Svante Schubert
>
> ABSTRACT
> This feature will improve document collaboration by focusing on document
> changes.
> It simplifies collaboration by exchanging only the document delta, thus
> fostering efficiency and meaningfulness.
>
> SCENARIO
> In the future when loading an ODF text document into this library, the
> document is being mapped to a list of high level user changes. This sequence
> of changes is equal to a batch of user actions, creating an equal document
> from the top to the bottom. 3rd party software such as web editors meant to
> receive this list (in JSON) to create their document representation. Similar
> they should gather their user changes as a similar change sequence and return
> them. This feature will enable the library to merge new changes back into the
> document.
>
> Changes have the advantage to abstract from design details of document
> serialization and will remain in general on the logical level known by common
> users.
> In addition, changes are atomic. They bundle the manipulation of sometimes
> scattered feature data into a single change step.
> Atomicity allows two adjacent changes within the change list to be switched
> without requiring further context, easing the alteration of work history,
> such as normalization.
>
> To allow compatibility of changes among office applications from the
> beginning and accelerate their development, there is an ongoing effort of
> standardization changes based on the ODF XML file format.
>
> BACKGROUND
> Prior to the upcoming OASIS ODF 1.3 version only the complete ODF document
> had been standardized. (For instance, its zipped XML files, the manifest,
> signature, encryption and RDF metadata).
> Therefore, the only interoperable way to synchronize changes between
> collaborating office users was the exchange of the complete document using
> change-tracking. Change-Tracking is always stored within the content,
> requiring to process the complete document content.
> This does not scale with multiple users working at the same time on a
> document. For instance, real-time collaboration requires instantaneous user
> feedback. Exchanging the complete documents on every synchronization among
> participants is not feasible.
>
> Similar it is in general less transparent and less safe to receive from a 3rd
> party a document including their changes in opposite to exchanging the
> changes alone.
>
> To alter this disadvantageous situation and be able to exchange predefined
> deltas of an office document, ODF changes are currently being standardized in
> the ODF Advanced Document Collaboration subcommittee of OASIS. An ODF change
> is a typical user change on "logical document parts", e.g. paragraph, image
> or text character. There are three change types: add, modify or delete. Every
> high level ODF change is going to be mapped by the specification to the
> manipulation of one or more XML nodes within the document. The abstraction
> from XML changes by these typed operation is necessary as most ODF
> application are not aware of ODF XML during the runtime. In contrast to HTML,
> ODF does not require a common model such as DOM.
> The serialization of changes will be offered in JSON by this feature as the
> common use case is to have the ODF Toolkit in the back end, while a web based
> editor receives such changes and renders the document.
> In addition to that, the ODF Toolkit will be capable to receive user changes
> made by a client to the document and merge them into the document by applying
> one change after the other on its internal ODF XML DOM model.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
