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: Re: [office-collab] RFC: DeltaXML-TC4/doc/odf-track-changes.odt andnumerical change IDs


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]