Flat File Packaging

[Dennis E. Hamilton]

OK, Outsider Observation:

Since this is a pure inter-conversion of OPC, it is not clear to me that this is really archive unaware, it is essentially differently archive aware.  

It also strikes me that digital signatures will certainly not be compatible [;<).  Is it assumed that can be done invariantly with bidirectional preservation of signatures?

There are encryption implications as well, if and when that comes up.

And, now that I think of it, there may be problems with xml:id used in parts that are now bound into a single XML document.  I didn’t check into how relations map and how fragment identifiers, relative IRIs, etc., are impacted either.  I must re-read that draft again to see if that is addressed adequately.

Finally, I also expect that anything but modest uses of this will use some sort of whole-file compression and we are rapidly reverting to the previously-objectionable problem, although single-file compression has simpler cases.  A clean Document Container File could be used, so it could carry just enough metadata so folks could figure out just exactly what the payload is.

I can imagine this form being preferred by producers that want to produce OOXML more economically in generating documents from other forms.  It *can* be potentially more useful for certain classes of consumers that want to mine and repurpose the document, but I think the fact that OPC structure is still there will create some modicum of heart-burn regardless.  I think the use case statement needs to be more concrete than stating a subjective negative.  I’m not sure what kind of interoperability imprimature this will or should have.  Do the proposers still want to be able to call it ISO Standard OOXML?  The interchange prospects seem rather narrow.

Of course, ODF has a flat XML format already and it is part of the specification.  It even survived into ODF 1.2 despite some limitations and a certain distaste for it among implementers.  Flat XML seems handy for folks who want to run XSLT against a single file, generate a file without using an ODF package, etc.  That’s not the fall-line case for office productivity, but advocates have a disproportionate voice, it seems, as if all performance is magically preservable.  Just to be clear, I *like* the flat ODF format, since it is very handy for test cases, tutorials, etc.  But allocating the cost of having it handy across all users is hard to justify, I think.  The ODF flat file is also not completely interconvertible, although that could be repaired by allowing more use of Base64 in-line encoding, as in the proposed approach.

- Dennis

Not representing any participating organization or consortium.


From: sc34wg6-bounces at vse.cz [mailto:sc34wg6-bounces at vse.cz] On Behalf Of Francis Cave
Sent: Tuesday, September 10, 2013 06:20
To: SC 34/WG 6 mailing list
Subject: REMINDER: Teleconference meeting of SC 34/WG 6, 2013-09-11 AT 15:30 UTC

Dear members of WG 6

I have not received any request for changes to the agenda, so tomorrow's teleconference meeting of WG 6 will proceed with the agenda as previously announced.

I have one item to raise under item 7 Any other business, which will be to raise an issue that has arisen in WG 4 discussions concerning flat file formats for office documents. The attached document is an informal working draft of a possible New Work Item for WG 4. The question has arisen as to whether such a flat file format should be specific to the document file format(s) to which it relates or should be generalised for any documents that are XML packaged in a container format. WG 4 experts would be interested in the views of ODF experts on this question, and I agreed to raise it in the WG 6 teleconference meeting. We will only discuss it if we have time.

Francis Cave
Convenor


[ ... ]