[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"
Hi Dennis, > You say that " ODF already has the version mechanism that allow to > save multiple versions of a document alongside in one document > container; adding a new version provides a crude form of document > history. But the versions are disjunct - it is not clear > what the one has to do with the other." > > I concede that, since ODF packages use Zip as a carrier, there is > nothing to prevent other versions of a document from being > incorporated in some manner. > > 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/" xmlns:VL="http://openoffice.org/2001/versions-list"><VL:version-entry 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="" manifest:full-path="Versions/"/> 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. Best, Michiel Leenaars NLnet Foundation
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]