[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.odt andnumerical change IDs
Ben, Sounds good re numeric IDs, thanks. A change-id attribute is not intended as human-readable. I think if we need a human-readable then this should not be in an attribute but as PCDATA in markup (but that is just my opinion!), and this was the intention of the delta:change-log as you suggest. We need more precise descriptions of these elements so that the intention is clearer. I hope this answers your question, sorry about delay in responding. Robin monkeyiq wrote: 1292311541.7392.138.camel@alkid.localdomain" type="cite">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 -- -- ----------------------------------------------------------------- Robin La Fontaine, Director, DeltaXML Ltd "Change control for XML" T: +44 1684 592 144 E: robin.lafontaine@deltaxml.com http://www.deltaxml.com Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]