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: ADC Requirements Summary


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



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