Patrick,
Answers inline below. I hope to make the call on Monday provided
another meeting does not run over and I can access ok while out of
the office.
Robin
On 18/05/2012 01:00, Patrick Durusau wrote:
Robin,
More tomorrow but for tonight:
OK, when you say text or table you mean anywhere in the ODF format
where PCDATA can occur and/or any changes to the structure of a
table for a *text* document, those changes must be capable of
acceptance/rejection.
Yes, it is changes to the 'content' that they need to be able to see
and accept/reject. Table structure is a problem... the workaround is
to show 'old table' and 'new table' because some changes are very
difficult to represent graphically, for example when cells have been
merged. It is also very difficult to work out what has been changed,
but that is our problem not yours! That said, note that in
comparison there is no information on what a user actually did, e.g.
we have to work out that a row/column has been deleted or cells
merged, and it would be difficult to relate these always to specific
author actions.
May I assume that the maker of the changes is always logged? No
anonymous changes?
Not exactly: generally in comparison one has no knowledge of who may
have made the changes, e.g. version 3 edited by John to version 4,
then Dave edits that to get to 5. Compare 3 with 5 but there is no
info on who changed what, but we can find all the changes.
Along with the date of changes?
Interesting requirement concerning changes to auto-generated
indexes (TOC is a type of index) and list numbering.
Other auto-generated materials? page numbers? footnotes? caption
numbering?
Potentially - page numbers less likely, footnotes yes for sure
changes need t be shown (and perhaps changes to the footnote
number). This has been a difficult area to implement because it is
not easy to work out list numbers, as you will know!
BTW, I assume that where there is original document A, to which
changes are made, resulting in document B, and document A is also
changed by another user to make document C, that your client would
recognize there can be some conflicting changes where cannot be
automatically merged.
Yes. You can play with it and see for yourself on our website (the
product is not supported, but you can download and use it).
http://www.deltaxml.com/products/odt_merge/
http://www.deltaxml.com/products/odt_compare/
Both B and C start from the same original but make inconsistent
changes to their copy of the original.
Yes, we merged into tracked changes as far as possible so an author
could accept/reject and thus decide on any conflicts.
Hope you are having a great day!
Patrick
On 05/17/2012 05:28 AM, Robin LaFontaine wrote:
In preparation for Monday's call, here is a
brief statement of requirements for our customers who need,
for very good reasons, to know the differences between two
documents and also to merge changes made to copies of one
document.
Our application using ODF is in comparing documents,
specifically ODT. The customer that originally sponsored this
work was submitting large legal/financial documents to
regulators and they required that every change to any
text or table was shown in the result. (They did not require
changes to format to be shown though we have had requests from
others for this. But they did want to see changes to generated
information such as table of content and list item numbers.)
As ODT 1.1 track change format was so limited, we had to do
this using text decoration which had the limitation that
changes could not be accepted/rejected, only viewed. Viewing
the changes was, however, their main requirement for
submission to regulators, so we managed to provide a solution
for them despite limitations in ODT 1.1.
We were also asked to write a merge tool so that multiple
lawyers could change different copies of the document at the
same time and then the changes are merged together. Again, we
were very limited due to the capabilities of the
change tracking format in ODT 1.1. For this application to
work properly, every change that an editor can make
needs to be represented, i.e. any change to the document. This
is essentially a non-real-time (batch) collaboration
requirement. The importance of change tracking here is to
enable accept/reject changes and to allow conflicting changes
to be handled.
If ODT is to be useful for legal and legislative documents
then it needs to be capable of tracking even minor changes -
lawyers and regulators are very particular, for good reason.
Note: Due in part to the limitations of ODT 1.1 change
tracking, our customer was forced to move away from ODF. If
the change tracking had been better, the story might have been
different.
Robin
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Experts in information change"
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
---------------------------------------------------------------------
To
unsubscribe, e-mail: office-collab-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-collab-help@lists.oasis-open.org
--
Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
OASIS Technical Advisory Board (TAB) - member
Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
--
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Experts in information change"
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
|