[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office-collab] RFC: DeltaXML-TC4/doc/odf-track-changes.odtand numerical change IDs
Ah excellent point re numeric IDs. For now I'll just assume the change-ids are arbitrary XML attributes and reassign numeric monotonic numbers on document load based on the revision time from the change-info element. Should the change-id attribute used in the delta:change-id be taken as the human readable description of this change ID to show the user or should we use an attribute inside delta:change-info (delta:change-log in the below example) for this human targeted information? If we want to have an explicit attribute for the human description, perhaps we should update section 5 of odf-track-changes.odt to include this in the example too? Sorry if this is already the case but I missed it :/ On Mon, 2010-12-13 at 11:27 +0000, Robin LaFontaine wrote: > Ben, > > I am certainly in favour of making things easier for implementers. > However, there are dangers in overloading the ID to effectively contain > some timing information. For example, when we do a comparison between > two documents, we may list the changes as track changes but we have no > information on when these were made, so by default they are all given > the same timestamp. However, their IDs would be different, in order that > the changes can be accepted or rejected independently. > > There is, as you say, another way of finding out this information. > > Regards, > Robin > > monkeyiq wrote: > > 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. > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]