[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]