[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] A few thoughts on ODF change tracking
robert_weir@us.ibm.com wrote: > 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. +1. We have already conducted a public review, and we are now in a phase were we resolve serious issues, but not where we add features. > > >> 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?" Right. We must also consider that the TC has agreed to not any new feature a long time ago. We should respect that decision, because many TC members since when wait for integration of their proposals, or may even have not submitted them because they are not considered right now. That is, for fairness, we should treat all proposals the same. We should also consider that the ODF TC works entirely in the public. That is, the fact that we are finalizing ODF 1.2 right now should be well known. Best regards Michael > > >> 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 >> > > > --------------------------------------------------------------------- > 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 > -- Michael Brauer | Oracle Office Development Phone: +49 40 23646 500 Oracle Office GBU ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]