Re: [office] A few thoughts on ODF change tracking

[robert_weir@us.ibm.com]

Patrick Durusau <patrick@durusau.net> wrote on 09/21/2010 03:34:29 PM:

> 
> Rob,
> 
> I think part of the issue is simply one of resources. With everyone at
> near max trying to resolve/apply all the remaining issues, there simply
> aren't enough resources for "complete" review, acknowledging that there
> is no "complete" change tracking.
> 


That is something for each TC member to weigh for themselves:  The benefit 
of delivering the enhancements and improvements that ODF 1.2 already has 
based on the 3 years of work that has gone into it, against the 
enhancements and improvements that we could continue to add to it by 
holding back on approval of ODF 1.2.  I think we're a point now, where the 
draft is pretty darn good in a lot of areas, and that any further delay 
means holding back completed work.  It was different maybe a year ago, 
say, when there was room to develop new features as OpenFormula finished 
up.  But now all the pieces have come together.  We can't add more without 
delaying the approval and publication of the work that is already done.


> Having said that, Oliver has devoted a good deal of effort to producing
> a coherent solution and one that may serve us for ODF 1.2.
> 
> Not to look too far into the future, should some NB take exception to
> the change tracking in ODF 1.2, it may well be the case that if that and
> some other obvious topics are treated as part of the next release, we
> may have the time/resources to produce a version by the time to answer
> NB comments that addresses those concerns.
> 
> I don't mean to suggest that as a means to avoid fixing any known issues
> with the current version but I do mean to suggest that if we can devise
> a schedule after ODF 1.2 is out the door for the production of
> subsequent versions, that will encourage a better development process.
> 

It is a non-goal for me to make everyone happy.  It is clear that for 
every person who will say, "Why did you approve ODF 1.2 without X?" there 
is another person already asking, "Why is taking you so long to complete 
ODF 1.2 so we can have Y?"


> Before any implementors work on "complete" change tracking, I would
> really like to see RDF based metadata support.
> 

Have you seen the work in KOffice and Freoffice?  We're starting to see 
implementations.

Regards,

-Rob

> Bringing intelligence to "dumb" documents is like buying foreign
> language dictionaries in hopes a class will learn a foreign language. A
> few may, but very few. 
> 
> A smarter web needs to start with smarter documents. ODF/RDF metadata is
> a step in that direction. 
> 
> Hope you are having a great day!
> 
> Patrick
> 
> On Tue, 2010-09-21 at 13:29 -0400, robert_weir@us.ibm.com wrote:
> > A few thoughts on change tracking.
> > 
> > What would make this feature "complete"?  I think change tracking is 
> > complete if an application can record any change to the end-user 
semantics 
> > of the document.  This includes things like changing the visible 
content 
> > of the document, but also changing the metadata.  It does not include 
> > changes that have no end-user semantic value, e.g., changing an xml:id 
or 
> > automatic style name to a different value, provided the referential 
> > integrity is maintained. 
> > 
> > I should be able to take two arbitrary ODF documents of the same type, 
say 
> > text documents A and B, generate a diff of them and encoded that diff 
of A 
> > to B as change tracks on A, such that when I accept all tracked 
changes in 
> > A I get something semantically equivalent to B.
> > 
> > Given that as a goal, I think we need to get it out of our heads that 
any 
> > standard or implementation does change tracking completely today. 
> > Everything I can find has some notable areas of missing functionality.
> > 
> > Aside from the issues already noted in JIRA, consider:
> > 
> > - It is possible for a named style to change its definition, without 
> > changing anything in content.xml.  For example, I could have a style 
> > called "hidden" that is defined as white text on a white background, 
and 
> > then unhide it later by merely redefining the definition in 
styles.xml. 
> > How is that tracked?  MS Word does this, and in the UI appears to hint 

> > that it is a change to the document as-a-whole rather than any 
particular 
> > content.  This seems reasonable.
> > 
> > - It is possible to replace an image file with an identically named 
image 
> > file but with different content.  How is that tracked? 
> > 
> > - Similarly, for any object embedding, OLE or whatever, how are 
changes 
> > tracked? (MS Word doesn't seem to track these changes)
> > 
> > - And what about MathML, a special kind of object in ODF?
> > 
> > - And what about sub-documents?
> > 
> > - Or RDF XML metadata?
> > 
> > - Or Changes to the manifest, such as adding a new resource, not 
> > necessarily references from content.xml
> > 
> > - And what about presentation files, which appears to lack support 
even in 
> >  OOXML? 
> > 
> > So change tracking, if you want to be complete, needs to deal with 
changes 
> > at the packaging level, in all of the defined XML's, as well as 
changes in 
> > linked resources, such as jpeg images and RDF XML.  As far as I can 
tell, 
> > no application and no standard does complete change tracking.  So I 
> > suggest we don't take it as a last-minute goal for ODF 1.2 to achieve 
> > completeness there. 
> > 
> > However, inability to do everything is not an excuse not to do 
nothing. If 
> > we can extend the current change tracking approach to some of the more 

> > commonly-reported pain points, like change tracking if table row 
> > deletions, etc., then this would be good.  But I'd propose that before 
we 
> > move to a new and incompatible representation of change tracking that 
we 
> > sit down and work through the entire semantic content of an ODF 
document 
> > and ensure that we're using an approach that is capable of recording 
> > changes across the entire range of possible document edits.  This is 
> > important, and worth doing, but worth doing right.  The proposal 
submitted 
> > via the comment list appears to be an excellent start, but we need to 
> > expand it to cover some of these other use cases, if we want to claim 
> > completeness. 
> > 
> > Regards,
> > 
> > -Rob
> > 
> > 
> > ---------------------------------------------------------------------
> > 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 

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