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