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: RFC: DeltaXML-TC4/doc/odf-track-changes.odt and numerical changeIDs


Hi,
  While reading the track changes spec and hacking support for it into
Abiword, I've noticed a few things which might make life easier for
other implementers if they were accommodated in the spec rather than in
each application implementing it. 

   There are cases such as this one where the existing code I am working
with uses numerical IDs. So I can either hack a lookup map to translate
string<->id or have the spec enforce that ids are as described below and
perhaps other applications can rely on that too.

Explicitly I refer to the idrefs for Change IDs. 
Looking at the Change Transaction (CT) Structure section of the document
referenced in the subject line, the form of a changeID is left
reasonably open. In abiword, a revision (or change id) can have a user
defined name and gets an internal "ID" which is a monotonically
increasing integer.

 <delta:tracked-changes>
    <delta:change-transaction delta:change-id="1">
      <delta:change-info>
        <dc:creator>Ben Martin</dc:creator>
        <dc:date>2010-12-09T02:34:50</dc:date>
        <delta:xvers>0</delta:xvers>
        <delta:change-log>All your base are belong...</delta:change-log>
      </delta:change-info>
    </delta:change-transaction>
    <delta:change-transaction delta:change-id="2">
...

I am using the change-log element for the user's description of a
revision at the moment, though a name field might be more appropriate.
Having monotonically increasing integers for the change-id references
has the advantage of being short, not subject to user input in the
change-id attribute, and obviously if idn < idj then it is an earlier
revision.

I am wondering if such requirements for the change-id would be
appropriate in the spec itself so that all applications can rely on
this. Obviously one can do a 

change-transaction-lookup-dc-date-time_t("ct3")
  < change-transaction-lookup-dc-date-time_t("foo7")

to find out if ct3 is older than foo7 using the existing spec, so it
becomes a question of if folks think using numeric IDs would make their
implementation easier too.




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