[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal for new document element, "Document history"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear TC members, given the recent developments on track changes, and especially the forthcoming discussions on two proposals to significantly enhance the feature set of ODF in this area, I would like to propose to create a new primitive for life cycle management of documents: "Document history". This would technically be quite similar to the already existing "Table of contents" and "Index", but instead of tracking headings of certain levels to page numbers it would map alterations of the document as captured by the track changes history and the document versions linked to their position in the document (chapters, sections, pages - at the preference of the user). Many official documents (including standards) are reviewed periodically to accommodate for errata and new requirements and insights. In order to keep track of what has happened such documents have a dedicated section (in some cases a table with three columns: date, description of the change, author; in other cases textual or in a list) so that the reader can understand the revision history of a document. As is these have to be manually crafted and maintained - while all of it could be done automatically with relative ease, which would save a lot of time and would allow for a more thorough (technically verifiable) audit trail. Also, such a Document History would be persistent when archived to other formats (e.g. PDF-A). ODF is a popular format within governments, and such a feature would therefore be very relevant for that target group. I have focused on the track changes proposal by Robin Lafontaine and Tristan Mitchell from DeltaXML [1], as it seems most suited for that proposal. Given the exact and complete nature of the representation of changes proposal it would only require some trivial additions to the proposed CT markup: * the addition of a 'friendly name' or Change Description (which would be typically what the user would already see in the current 'undo' stack or revison record {Microsoft Office Excel, [2]} of many products) to a Change Set: - "Delete table row" - "Insert end note" - "Apply style: Heading 1" - "Change cell background color" - "Inserted RDFa metadata" - "Rename an existing sheet" - "Removing a custom view" - "Move image" The change description is 'self declared' by the application to allow for maximum flexibility (the exact changes are in the change set and do not allow for any ambiguity, the change description is just a tag, a communicative tool to help the user and his audience understand in human readable form what happened to a document). The Change Description is generated by the application the author of the changes is using, when he or she makes those changes - so they make sense in that context. An application might however offer the possibility to use a certain more formal syntax (similar to different notations in bibliographical entries). Typical examples would be ISO standards notation. In that case an application would have to store the URI to that notation alongside the Change Description. The application knows quite a bit more about any given change than just its type, and it could (possibly at the discretion of the user) add this to the friendly name: - "Replace 34 instances of #search term# to #replacement#" - "Delete 'First...Last' The software should not add the context (position in the document and the document hierarchy) to the Change Description, as this context might need to be recalculated later to make sense to the reader of the final document. The user should be able to opt for manually edit Change Descriptions (or soft block manual editing), just like he is allowed to with Tables of Content. [ODF 1.2 par 19.849 "text:protected" offers such a 'Protected mode'] * the second addition would be that the bundling of changes into a change transaction would be allowed recursiveness. I.e. this would allow the user (or the software on his or her behalf) to bundle some changes where this makes sense. For instance a number of minor changes in a single paragraph is more friendly to represent as "Modifications to par # of section # on page #" than as fifteen separate insertions and deletions, or (in a situation where multiple people are responsible for different types of edits) changes made by a certain author or in a certain release of a document. Bundling of changes in a graphical interface could be done inside revision mode or directly in the document itself - similar to grouping of drawing objects in the context of a document (select a number of objects or a region, use a hotkey/icon or right click and choose the appropriate option 'bundle changes'). Alternatively, this could be done by selecting the changes that need to be bundled in a "Document history" that was already generated. Obviously, since this is a new primitive, some additional changes to the main ODF format should be made as well: * If there are multiple versions of a document, those could be used to track document history beyond the currently present track changes. After changes are approved, they otherwise disappear. Inclusion of a history.xml file with approved prior modifications of the document could be an option. * The application can calculate the context from its knowledge of the document: while the friendly name just states "Replace 34 instances of #search term# to #replacement#" it knows that this impacts pages 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377 and 610. Equally, the hierarchy in the document is known, so that it knows where "Move 'First...Last" takes place, and the application can position it. E.g. "1.1 Introduction" -> "1.2 Terminology". As a suggestion the 'Document History' primitive could be part of chapter 8. Text Indexes, with a new <text:document-history> element. Suggested elements that can (at the choice of the user) be shown in a "Document history" are: - Date - Time - Author(s) - Document version - Change content friendly name (- Electronic signature of the changes) - Position of change (chapter/paragraph level 1/10) - Change set ID - (Ranges of) page number(s) involved A "Document history" would be included in one of three forms: - - as a table (in spreadsheets this would be a separate sheet with the tabular data in regular spreadsheet rows). - - As positioned text (similar to Table of Contents), with a user choice of separator text/elements. - - As a list I hope this proposal will be of help. If you need some clarifications, examples or use cases, I will be happy to provide these. Kind regards, Michiel Leenaars NLnet foundation [1].http://www.oasis-open.org/committees/download.php/41512/generic-ct-proposal.odt [2].http://msdn.microsoft.com/en-us/library/dd949743%28v=office.12%29.aspx -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2a5aAACgkQPPKB2FVlk1+pbwCePBEbtnY+YTw9Px75NUs+9okX wmkAn15F5Krr8J3Vju95eBKjeMW+jQkq =Tdkl -----END PGP SIGNATURE-----
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]