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] Preservation question




On 7/2/07, Patrick Durusau <patrick@durusau.net> wrote:
Greetings!

I have searched for work in OOXML that addresses the question of
preservation of metadata.

I think what comes closest is the following section:

> 9.1.9 Unknown Relationships
>
> All relationships not defined within this Standard are considered
> unknown relationships. Unknown relationships are valid within an
> Office Open XML document provided that they conform to relationship
> markup guidelines as defined by the OPC specification. Specifically:
>
> Conforming consumers shall not fail to load a document containing
> unknown relationships.
>
> Conforming producers are encouraged to roundtrip and preserve unknown
> relationships and their target parts.
I don't take "encouraged" to be the equivalent of "shall." ;-)

Hope this is helpful.

I think it's not particularly enlightening, in the sense of instilling confidence that Ecma got it right. Recall that Microsoft does not implement OOXML itself except as an import format. MS Office does not write to OOXML, which is a subset of its own formats (MOOXML). In that context, what really matters is what Microsoft's internal documentation requires and that is an unknown element.

It is to be expected that Microsoft would allow itself discretion in the OOXML spec to destroy "unknown relationships" created by others' applications when MS Office imports their files. That avoids the danger of OOXML actually becoming an interoperable set of formats, much as Sun has done with ODF and destruction of its foreign elements and attributes. I note that Sun remains silent on my requests that it explain *why* it wants discretion to destroy xml:id attributes as well and has yet to offer a single use case on why it might be necessary.

And if we changed the foreign element and attribute preservation requirement to "SHOULD" instead of "MAY," would that persuade Sun to do the right thing? I doubt it. But my point is that an application that thwarts interoperability SHOULD be branded as non-conformant.

In my opinion, the task this TC SHOULD be concerned with is to turn the following lie into truth through conformance **requirements:**

"The merits of ODF have already been established by its wide industry adoption. As noted above, numerous PPA vendors have implemented support for it in their products both on Windows and on other operating systems. Such widespread adoption is only possible *****because ODF is**** fully disclosed and ****created to allow for document interoperability by making it easy for various applications to exchange documents with full fidelity, i.e., without any loss of data or formatting of the document."*****

<http://www.ecis.eu/inter/documents/ECIS_ODF_OOXML_comparison.pdf >.

If this morning's discussion of "SHOULD" in the context of preservation of meta information is any guide, this TC is content with the ECIS/Sun/IBM lie about its previous work.

 


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