Flat File Packaging
Dennis E. Hamilton
dennis.hamilton at acm.org
Wed Sep 11 18:00:46 CEST 2013
Ah, so IS 30114 where this is 30114-3 is about Extensions to Office Open XML File Formats. Got it. I saw no title page, but it is on page 1 of the text and I overlooked it.
I guess I don't have any concerns about that being tied to OOXML, specifically.
Are not fragment identifiers usable in the target IRI of relative-referencing relationship elements? Maybe I have misunderstood that.
So this is very much restricted to the existing conditions under which OPC is usable. I would say that this is definitely not interesting in situations where OPC is not incorporated or even available by extension. The inability to use fragment identifiers is a problem, I think, for any harmonization of ODF and EPUB with OPC, and that will make life interesting if Document Container File moves beyond core. But that's not specific to 30114-3.
Thanks for the clarification.
From: Alex Brown [mailto:alexb at griffinbrown.co.uk]
Sent: Wednesday, September 11, 2013 00:28
To: dennis.hamilton at acm.org; 'Francis Cave'; 'SC 34/WG 6 mailing list'
Subject: RE: Flat File Packaging
I think you raise some good points. In previous discussions Jirka Kosek commented that this proposal reminded him of XInclude, where what appeared simple on the surface in fact contained some rather murky depths (such as handling of xml:id). OOXML, of course, doesn't use xml:id (or any kind of ID) and so sidesteps that particular issue.
Just as a side note, this flat format has been implemented for a while in some MS Office products. If you save OOXML using "Save As..." in MS Word 2010 for example, one of the available formats is "Word XML Document". The format that will be saved is flattened OPC as described by the spec Francis circulated. OOXML also has an option for specifying an XSLT transform that shall be applied on the fly when such documents are saved (but nowhere specifies how the document-that-will-be-transfomed shall be constructed).
From: sc34wg6-bounces at vse.cz [mailto:sc34wg6-bounces at vse.cz] On Behalf Of Dennis E. Hamilton
Sent: 10 September 2013 17:06
To: 'Francis Cave'; 'SC 34/WG 6 mailing list'
Subject: Flat File Packaging
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.
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.
[ ... ]
sc34wg6 mailing list
sc34wg6 at vse.cz
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com ______________________________________________________________________
More information about the sc34wg6