OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [office-comment] Proposal for new document element, "Document history"

Oh my goodness.

OK, I think I understand what you are asking for.   At this point, I am afraid to ask more questions.

This raises other issues that will be quite material in how today's work on change-tracking must anticipate future prospects for higher-level collaborative activities.  We need to be careful what we end up foreclosing as future prospects.

An in-document versioning/snapshot model that is also designed to avoid redundant replication is very interesting (though I have a nagging concern for existing IP that may be out there on this kind of provision).   It also seems to me that we are talking of some sort of cross-session Undo/Redo prospect, since all of the information seems to be retained for that (including accepted changes, more than the current retention of only those changes needing-review-approval-rejection determination).

Since we are talking about major new functionality on this thread, we have probably gone as far as we can in clarifying what you have in mind and that you even have implemented examples of it (which I find quite astonishing, personally).  It seems that the only way forward is if someone on the TC sees fit to work up some technical proposals and slide them into the ODF-next roadmap, either for ODF 1.3 or beyond.

 - Dennis

Speculative Side Notes -- not reflecting any consideration by the ODF TC:
 1. I think attention to the up- and down-level interoperability cases that are going to have to be addressed, and what that does for existing documents that will exist at the time, especially in areas of civil administration, may be quite daunting.   I would not be surprised if we are talking about ODF 2.0 for all of this and I have no idea what the break from the ODF 1.x progression might have to be.  Just speculating.  It is my intuition that what you are requesting cannot be handled by simple accretion to ODF as it now is.

 2. A limitation of ODF packaging is that relationships among the parts of a package are not identifiable at the package level (e.g., some sort of structure that allows copy-on-write avoidance of redundant duplication across versions).  Personally, I think of the Open Packaging Conventions use of package-level relationship parts for tracing dependencies as something tailor-made for this.  Of course, that is what makes OPC look too complicated until the problem it solves is found to be unavoidable. 

-----Original Message-----
From: Michiel Leenaars [mailto:michiel.ml@nlnet.nl] 

Sent: Thursday, April 07, 2011 01:46
To: office-comment@lists.oasis-open.org
Subject: Re: [office-comment] Proposal for new document element, "Document history"

Hi Dennis,

[ ... ]
> However, I know of no provision in the ODF specification that 
> recognizes such a mechanism.  In fact, since there is a single 
> manifest for any package, and there can only be one top-level 
> content.xml file, it is not clear to me what interchange arrangement 
> is supported.  (Indeed, some consumers would likely delete extraneous 
> content on which there is no apparent dependence, often for security 
> reasons and especially if some reasonably serious digital signing is 
> to be done.)
> Can you say more about that, or is it an "out-of-band" arrangement 
> that does not rely on any provision of ODF other than its being 
> neutral on the matter?

I thought I should have looked that up. Apologies. As it turns out, this is indeed as you describe an 'out of band' arrangement - although it is present in a number of products I have used over the years (i.e.
OpenOffice.org, LibreOffice, Symphony, NeoOffice, Go-OO etc.). As you say such behaviour is technically allowed by the specification (i.e.
may still produce valid documents) but it is not explicitly specified in ODF and not very interoperable as such - and from the looks of it should be described as an ancient 'quick hack' that never was updated (in the XML file which internally logs the versions these applications mention a 2001 namespace).

I note that the behaviour in LibreOffice (which I currently have on my
laptop) is as such:

- a dedicated folder ("/Versions") is created inside the package
- the version of the document the user wants to save is added as a full
  (non-serialized) ODF file to that folder
- a new XML file, VersionList.xml, is created in the root of the package

<?xml version="1.0" encoding="UTF-8"?>
<VL:version-list xmlns:dc="http://purl.org/dc/elements/1.1/";
VL:title="Version1" VL:comment="Yada yada" VL:creator="Michiel Leenaars" dc:date-time="2011-04-07T09:16:46"/></VL:version-list>

- Everything above is added to META-INF/manifest.xml - note that this
  is done without media-type, even for the xml file

 <manifest:file-entry manifest:media-type=""
 manifest:full-path="VersionList.xml"/> <manifest:file-entry  manifest:media-type="" manifest:full-path="Versions/Version1"/>
 <manifest:file-entry manifest:media-type=""

Currently, at least in LibreOffice 3.3.2 a simple test (add a line of text, save as document version) does not produce a valid ODF file.

I would urge the ODF TC to look at standardising a snapshot/version mechanism. Note that vastly more efficient mechanisms could be found than recursively adding full documents. This should include sharing at least media objects (which tend to be a large contribution to file
size) across different versions of a document. Perhaps a full history mechanism as I described would be even more elegant, since at least it is my assumption that people use versions essentially for document history purposes. Also, it should be possible to have electronic signatures of different version.  

[ ... ]

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]