RE: [office] Single XML file

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

André,

The work to integrate the schemas for the parts (content.xml, styles.xml, etc.) and the single XML document has already been done.  That basic structure has not changed as the result of evolution of the specification from ODF 1.0 through ODF 1.2 and it need not change for ODF 1.3.  Any radical change-tracking changes will impact the single XML only a little and the package-level bits a great deal.

There is some extra wording in the conformance section to deal with conformance of single XML documents versus the kindred packaged documents.  That could probably be simplified but, again, the work has already been done.

David LeBlanc is correct, specifying a particular case for XML DSig introduction in the single XML document does require something in the specification.  Ideally that would be at the <office:document> element, the unique root for the single XML document.  There are the usual rules for how the signing is done when the signature is embedded.  It's a little trickier for XML just because it is not a binary format and canonicalization enters into the picture.  Other than that, it is not much different than inserting Authenticode signatures into compiled binaries, it seems to me.

If there were an informal agreement on XML DSig introduction, it could be done immediately.  Since it can be ignored as a foreign element under the <office:document>, it should not disrupt any implementation except one that wants to be strict about foreign elements and do something more disruptive than simply ignore them.  (Likewise for RDF elements.)

 - Dennis



-----Original Message-----
From: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of André Rebentisch
Sent: Friday, August 31, 2012 15:39
To: office@lists.oasis-open.org
Subject: Re: [office] Single XML file

Am 31.08.2012 23:48, schrieb Dennis E. Hamilton:
> I agree that the single XML file is very utilitarian.  It is adaptable to a wide variety of special-purpose uses and it is easy to generate, even manually and with or without a schema-aware editing tool.

* The discussion so far addresses the usefulness of the Single XML 
incarnation but leaves the question open if Single XML should be a 
derivative deliverable of the TC/OASIS/... or remain a part of the 
upcoming 1.3 standard, which then essentially continues to comprise two 
twin file formats.

A key criteria here appears pace of standardisation. Does Single XML 
inclusion slow the process down? Patricks resource concerns apply.

* The second question from my side is structure, editorial, do you 
perceive it as appropriate to list both as equivalent options, or should 
the Single XML option be moved to a dedicated chapter ("part) which 
describes the alternative file format option, and derivations from the 
mainstream packaged ODF if any? The latter would allow to avoid 
underspecification and unclutter the structure. It also would enable us 
to better understand and monitor a potential feature gap, and keep the 
main stream format documentation clean from unnecessary variants,

* The third issue I would like to raise is inline elements. For instance 
we have the options to link packaged binary items and scripts or include 
them inline. Would it be useful to take a decision for the 1.3 
incarnation producer in the sense that inline is only applicable for 
Single XML format but not packaged ODF 1.3?

The more variants the format provides for producers the more complexity, 
the more implementation specific differences and potential 
interoperability challenges in a cross-implementation roundtrip 
environment arise.

Best,
André






---------------------------------------------------------------------
To unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: office-help@lists.oasis-open.org