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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

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


Subject: Advanced Signature Scenario


When signing an ODF 1.2 document, technically a set of XML files is
being signed. Assuming that all content files are being signed it is not
possible to edit and resave the document without breaking the signature
and to  resign the content.
User scenarios as the commenting on an signed documents from an
different user, does not work. Still in a work flow often a business
document (e.g. iInvoice/request) have to be signed from the author and
have to pass several steps within a work-flow. Therefore it was often
desired by ODF customers to be able to comment on the signed document
and sign their comments.

This would be possible with MCT as all changes are being saved aside of
the content.xml, styles.xml, etc. (ODF XML files for the following).
In this case the operations will not be saved in the ODF files, but
within the redo.xml file.
If this is a valid scenario the design requirement for MCT comes on the
table to be able to split/merge various set of operations for each user,
as each operation queue have to be signed independently.
The split and merge is no problem as it is already covered by
Operational Transformation (OT) [1].

This scenario is similar to the one previous on this list, where the ODF
specification is being tracked from the beginning and the ODF 1.2
version is being saved back to a ODF 1.1 version.
To do this the latest state of the content.xml (etc. ODF XML files) is
being loaded and altered step-by-step from serialized operations from
the undo.xml stack. While doing this, no information should get lost,
therefore for each removed unto operation an inverse operation is being
saved in the redo.xml stack to be able to get back to the ODF 1.2 state.
For example, if a document of "version A" only includes the single
character "a" and this character is being exchanged with a "b" (removing
"a" and inserting "b"). The "version B" only includes the undo.xml of
removing "a" and adding "b". If the history feature is being used to
save the document back to "version A", the operations of undo.xml are
being applied to the content.xml and a redo.xml is being created
containing the deletion of "b" and the insertion of "a".
Long story short, it is possible to go through document history, by
applying the operations of the undo.xml/redo.xml stack upon the ODF XML
files and creating for every applied operation a new inverse operation
to the redo.xml/undo.xml.

If someone would now still like to edit the ODF 1.1 document, the
changes to ODF 1.2 do not necessarily lost. Instead a branch is being
created. This makes a lot of sense, if someone would like to keep ODF
1.2, but would like to create a new maintenance version of ODF 1.1, like
the ODF 1.1 errata document.
(If someone is remembered on existing version system as GIT/Mercurial
this is not big surprise, as we all relying on the principle known as
directed acyclic graphs[2]. There might be several scenarios we can
learn from those, e.g. the versioning from binary data. For a nice -
very easy, very entertaining - introduction see "Tech Talk: Linus
Torvalds on GIT" [3]).

Please remember, it is not necessary that ODF applications have to
implement any of the above feature, it should just show what
possibilities MCT opens for the future for ODF applications.
In addition no existing ODF application have to change their core. When
the application was able to save a document at state A (the beginning of
a MCT operation) and is able to save at state B (the end state of an MCT
operation), the MCT operation is just a stack/batch of existing API
calls within the ODF applications. This works for browsers using an HTML
model, similar as for ancient ODF apps like Libre|OpenOffice and MS Office.

Best regards,
Svante

[1] http://www.waveprotocol.org/whitepapers/operational-transform
[2] http://en.wikipedia.org/wiki/Directed_acyclic_graph
[3] http://www.youtube.com/watch?v=4XpnKHJAok8



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