Below is a summary of some of the issues that were raised by various
individuals during our telephone conference call on 15th of December 2010.
It could be argued that some items should be moved from one category to
another, and that there is some overlap between them, but I don't think
that this really matters. It is more important that we have gathered
together a consensus of the issues that we need to address.
Please do comment on any individual items, and use the numbers and
headers in your e-mail subject, e.g. '1.6 Easy to script', so that we
know which issue is being discussed.
The only item that was not discussed during the conference call is item
1.7, and I would welcome any comments on whether or not we need this.
And of course please feel free to suggest any additional items.
1. What we need to keep
1.1 Simplicity
- simple but not too simple
1.2 Easy to remove
- easy to ignore i.e. to remove all tracked change and get final
document (all changes accepted)
1.3 All changes logged in one place
- changes are listed together so application only needs to visit one
place to find a list of changes
1.4 Use markup to represent changes not processing instructions
- uses markup not processing instructions so more versatile and easier
to process wth XSLT and other XML technologies
1.5 Can convert from existing change tracking mechanism to new one
- all changes recorded in current format can be converted, i.e. a
defined way to move to the new format
1.6 Easy to script
- easy to script e.g. scripts the ODF TC uses to accept all changes
1.7 Deleted text stored separately
- deletions separate from main text, so that all text in main body is
text of current (latest) document, see spec CD05 section 6.1.1. We would
break compatibility unless we keep to this.
2. What we need to improve
2.1 Interoperability between different implementations
- interoperability between different implementations, so specification
needs to be clear, precise and unambiguous
2.2 Interoperability with other formats
- interoperability with other formats e.g. Open XML, is needed so there
is the best potential to convert between formats
2.3 Stability of mechanism over long period
- stability so document changes can be recorded/preserved over a long period
2.4 Track all possible types of change
- track all types of change, e.g. across hierarchy, tables, styles etc.
2.5 Easy to process with XSLT
- easier to process with XSLT so that scripts can be written
2.6 Proven implementations
- needs to have implementations that demonstrate that it works
3. What we need to add
3.1 Future-proof
- future proof so no additional work needed on change tracking when new
ODF features are added
3.2 Covers all use cases
- covers all use cases provided by users and vendors
3.3 High degree of consensus
- needs to have high degree of consensus amongst subcommittee before
being submitted to TC
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Change control for XML"
T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com
http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK