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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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