[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Change tracking - collaboration - separation of concerns
Svante,
Sure, start with: https://standards.iso.org/ittf/PubliclyAvailableStandards/c071691_ISO_IEC_29500-1_2016.zip (so we are looking at the same file).
I had to hunt for the reference, I remembered it clearly but not the section number. This is under shared workbooks but the logic for documents is the same.
*****
18.11.1.16 revisions (Revisions)
This element represents the root node of a list of revisions made
in this shared workbook. This root node shows
up at the beginning of every log file that contains specific
revisions made to the workbook.
When multiple users are sharing, and editing, a workbook at the
same time, there can be conflicting changes.
The spreadsheet application should have logic to resolve such
conflicts, and the file format should only contain
enough information so that the spreadsheet application can restore
the workbook to the correct state after
conflict resolution. Revisions can also be tracked by the
spreadsheet application for review by the user at a later
time (as opposed to only dealing with conflicts on a save event.)
Some edits to workbooks are made as a result
of this conflict resolution. So, there are cases where a revision
is effectively undone by another user, and as a
result that undoing is itself a revision that adds or changes data
in the file. These operations are tracked by the
ua and ra attributes of many different elements.
*****
Examples follow but I have omitted those.
Of course "... the correct state after conflict resolution" is being a valid ODF instance.
Hope you are having a great evening!
Patrick
Patrick,
could you provide us with further information about the separations of concerns by ISO 29500?Do you have a direct reference?
Best regardsSvante
Am Mi., 2. Sept. 2020 um 21:35ÂUhr schrieb Patrick Durusau <patrick@durusau.net>:
Greetings!
I'm not at all sure we will reach change tracking/collaboration for ODF
1.4 but I have been reading / researching the issues relative to markup
and think we can greatly simplify the task before the TC.
As you may recall, there were numerous (endless?) discussions of how a
new paragraph would change the position of a current paragraph and what
happens to edits to the current paragraph and such.
I suggest we follow the separation of concerns adopted by our friends
over at ISO 29500 and find the reconciliation of collaborative edits
occurs ABOVE the level of markup.
The only responsibility of markup is to capture the state of RECONCILED
edits performed by an application.
What is exchanged between applications (one assumes the smallest part
possible) nor what applications do internally isn't our issue. All we
know is the result passed into markup from the application.
Separating that concern out, I suspect but don't know, that specifying
change tracking that mirrors or exceeds that in other applications is
eminently doable.
Not a formal issue, yet, but I wanted to test the waters on the issue of
separating concerns.
Hope everyone is having a great week!
Patrick
--
Patrick Durusau
patrick@durusau.net
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau
-- Patrick Durusau patrick@durusau.net Technical Advisory Board, OASIS (TAB) Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) Another Word For It (blog): http://tm.durusau.net Homepage: http://www.durusau.net Twitter: patrickDurusau
Attachment:
signature.asc
Description: OpenPGP digital signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]