[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]