OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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


Subject: RE: [office] Single XML file


The pros and cons are this - if you wanted to sign the root element, then you have to make an XPath transform to exclude the document-signatures node. Which then implies that implementers have to support XPath transforms, and they have to check that the transform that excludes the document-signatures node is the only one there, or they will get into trouble, security and otherwise.

If you do not want to sign the root node itself - say there's no important data, only child nodes, and the attributes on the root are also not important, then things become easier. You then make the document-signatures node a direct child of the root, and say that there has to be a reference covering every direct child, excepting the document-signatures. Note that we currently have an exclusion for a certain directory within the zip, so you should provide for an unsigned exclusion area for the single-file case, too. If any of my assumptions above are incorrect, then we need to figure something out.

There are some minor nuances with the canonicalization. A standard canonicalization will preserve the root node namespace, and that seems like what we want to do here. Canonicalization transforms do exist that allow a node to be put under some other arbitrary node, and not break signatures. I'd tend not to want to go that route. Whichever is decided upon needs to be documented in the standard.

-----Original Message-----
From: office@lists.oasis-open.org [mailto:office@lists.oasis-open.org] On Behalf Of Dennis E. Hamilton
Sent: Friday, August 31, 2012 4:29 PM
To: office@lists.oasis-open.org
Subject: RE: [office] Single XML file

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


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



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