Re: [office-collab] RFC: DeltaXML-TC4/doc/odf-track-changes.odtand numerical change IDs

[monkeyiq <monkeyiq@gmail.com>]

Since I'm now also using the DeltaXML Relax NG schemas to verify
content.xml in emacs, I noticed that the change-id are currently defined
as dcname which means they need to have leaving alpha:
http://www.w3.org/TR/1999/REC-xml-names-19990114/#NT-NCName

 
On Tue, 2010-12-21 at 14:14 +0000, Robin LaFontaine wrote:
> 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: 
> > 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