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"

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/";
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.  

Michiel Leenaars
NLnet Foundation

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