revision marks

From: Tomas Frydrych (
Date: Sat May 18 2002 - 06:59:07 EDT

  • Next message: Kenneth J.Davis: "UT_UCS4Char byte ordering question"

    After thinking some more about what David said, I suggest we
    introduce a single new attribute called revision which would look
    something like

        <[token, e.g., c] revision="-1;+2;-5;">some text</c>

    This would mean that this particular segment of text was marked
    for deleting in revision 1, put back in revision 2, untouched in
    revisions 3 and 4, and removed again in revision 5. This is how we
    would handle the display for a particular revision level cases:

    case A: user chooses revision explicitly mentioned in the attribute
        a) revision 1: hide this segment of text
        b) revision 2: display this segment of text

    case B: user chooses revision not mentioned in the attribute, e.g.
    revision 4
        We find the highest revision id lower than the id requested, in
        this case 2, and use it instead; we display the text. If the
        smallest revision id found is > 2, we will use implicit revision
        0, with a sign opposite of that of the smalles id we found (see
        an example below).

    To answer David's concern about changing a single letter within a
    continuous <c> ... </> span: this does not pose a problem, since
    by changing the attributes of a single letter, the letter will
    automatically be enclosed in its own <c> </> container on export.

    To our list of view types (Normal, Print, Web), we will add a new
    view Revision. In the non-Revision views the text of all revisions will
    be displayed (using different colours, etc.), and the user will be
    able to use commands Tools->Revisions->Accept Change and
    Tools->Revisions->Reject Change, which will deal with revisions on
    individual basis or within current selection.

    In the special Revision view, the user will be able to see how the
    document as a whole looks after a particular revision, plus will have
    commands Tools->Revisions->Accept Current State of Document,
    which will allow him/her to accept all the changes that resulted in
    the document as s/he is viewing it, and Tools->Revisions->Accept
    Current Revision, which would allow him/her to accept all the
    changes made by the present revision. The former command will
    be very useful for document management, from experience I can
    say that document that contains several layers of revisions is very
    unreadable; Accept Current State of Document will make it
    possible to remove old revisions that are no more needed.

    These two commands should probably request an explicit
    confirmation before proceeding, because utlimately in the Revision
    view the user will not see what changes were made, only what the
    final result looks like.

    The Accept Current State of Document command would work like
    this, say this is a segment of our document:

        < revision="-1;+2;-5">text1</>
        < revision="+1;-2">text2></>
        < revision="+5">text3</>
        < revision="+2">text4</>
        < revision="-1;+5">text5</>

    and the user is viewing revision 2:

    Any text in which 2 is the highest revision id present will be treated
    according to that revision, i.e., text2 will be hidden, text4 will be
    shown. Upon Accept Current State of Document, the fragment
    text2 will be deleted from the PT, while fragment text4 will have the
    revision attribute removed, i.e., it will become an ordinary text.

    Any text in which 2 is present but is not the highest id would also
    be shown using the id 2 attribute, i.e., text1 would be shown, but
    on Accept Current State of Document the fragment would not be
    deleted, instead all the id's <=2 would be removed from its
    attribute, i.e, we would get in the PT for text1:

        < revision="-5">text1</>

    Any text in which revision 2 is absent will be treated according to
    the highest id < 2 present, i.e., text5 will be hidden and text 3, with
    an implicit revision -0, will also be hidden. Upon Accept Current
    State of Document all revision ids smaller than 2 will be removed
    from the fragment, so that we will get in PT

        < revision="+5">text3</>
        < revision="+5">text5</>

    Consequently the document above in revision 2 will look

        text1 text4

    and the PT after the Accept Current State of Document command
    would contain

        < revision="-5">text1</>
        < revision="+5">text3</>
        < revision="+5">text5</>

    The Accept Current Revision command would work anologously to
    the Accept Current State of Document, except it would only
    remove the specific revision id, in our case 2, and delete only
    fragments that have no other revision than -2. So the PT after
    Accept Current Revision would look like

        < revision="-1;-5">text1</>
        < revision="+1">text2></>
        < revision="+5">text3</>
        < revision="-1;+5">text5</>

    As David suggested, we will add a new preference to issue warning
    when saving a document that contains revisions and annotations.

    We will also need an extra document attribute indicating which
    view should be used to display the document when first loaded, we
    should have this in any case so that if the document is saved in
    normal view it opens in normal view the next time (same goes for
    zoom factor). If the document is to be shown in Revision view, the
    attribute will also carry with it the particular revision id to use. There
    should be some very clear indication to the user what view is
    currently selected, and if appropriate, which revision ID.


    This archive was generated by hypermail 2.1.4 : Sat May 18 2002 - 07:07:59 EDT