Conceptualizing Change Marking

Dennis E. Hamilton dennis.hamilton at acm.org
Tue Jul 27 04:22:40 CEST 2010


Michiel,

I did not see this when it was sent out, 
<http://mailman.vse.cz/pipermail/sc34wg6/2010-July/000132.html>.
I think my spam filter ate it because it has a different e-mail address for
you.

I wanted to recommend this blog post to you:
<
http://www.azarask.in/blog/post/collaboration_made_simple_with_bracket_notat
ion/>.

There is a good discussion in the comments also.

I see this as a useful way to conceptualize the change-tracking cases.

Aza Raskin proposes using triples in brackets: [..1..][..2..][..3..].  The
first shows what is deleted (and can be empty), the second shows what is
inserted (and can be empty), and the third is commentary or metadata or
both, and can be empty.

In the comments, the idea was to label the groups, so that any part can be
omitted.  My variation is to use [- ..1..][+ ..2..][# ..3..] and now any
empty parts can simply be omitted.  Note that pieces of insertions can be
removed, by nesting.

This was designed for plaintext, so there is no concern about cross-cutting
a hierarchical structure.  (Like XML).  But the problem does come up if the
bracketing of an insertion is cut across in an additional change.  There are
also problems when there is an existing nested structure that must work.
But it is still great for visualizing what is involved.

APPLICATION TO ODF

Consider the conceptual structure {1 abc {2 de } fg {2 hi } jklm }

Where the numbers {1 and {2 indicate that these are different kinds of
brackets.  (Think different start tags.)

An interesting problem with ODF is when an user makes a change that is
effectively like this:

   {1 abc {2 d[-e } fg {2 h][+qrst] i } jklm }

So the changed version is {1 abc {2 d|qrst| i } jklm } where I added "|" to
show where the insertion begins and ends.

If we require that the removed part, [- } fg {2 h] be "well-formed" with
matched-up {...} pairs we have an interesting problem.

ODF hints at rules that rewrite the removed part so that it is well-formed
and so that a consumer of the document can correctly reject the change and
restore the deleted material.

These rules work: they are implemented in OO.o and the implementation works
interoperably.  (I have a proof of concept that I can show separately.)

The problem, and that is the main point in the great analysis that Doug
Mahugh provided on his blog over one year ago is that the specification of
the feature in the ODF 1.0/IS 26300/ODF 1.1 documents is defective, and it
can't be implemented without looking at what a successful implementation
does.  (Fortunately, it is not necessary to look at the code, but it is
necessary to look at the XML documents to see how it works.)   Note: There
may be places where ODF does not support change tracking where it is
desirable that it do so.  I am not talking about that.  I am addressing the
fact that there are common cases, including replacing the end of a list item
and the beginning of the next list item in a way that reduces the number of
list items is already handled correctly.

So there are two problems, as I see it.  First, the ODF specifications need
to be repaired so that the specified places where change history is supposed
to work already are supported by correct specifications.  The second matter,
which we should keep separate, is any addition of further change-tracking
features for cases that the repaired ODF specification does not handle.

This split is so that what is done for the new does not break what is needed
for the old. 

Meanwhile, I hope you have as much fun with the little change-history
triples as I have had since I found the bracket-notation article a few days
ago.  

 - Dennis

Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton at acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org 




More information about the sc34wg6 mailing list