[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]