Marbux,
I think you are deeply confused about the issue of interoperability.
Yes, ODF fully defines both syntax and semantics that enables
interoperability between applications that conform to ODF.
But, recall that metadata in particular allows users to define
information that is not defined in the ODF standard. That is to say that
a conforming ODF application may encounter information that it cannot
process or perhaps even recognize. Better applications will simply
preserve such metadata files so that when the document is sent to a more
robust application, that information can be used.
Now, on the issue of xml:ids. What does it mean to preserve xml:ids?
Well, what if I get a document with an xml:id on a paragraph element and
I delete the paragraph? And that paragraph was the target of some
metadata. Is that preserving the xml:id? What if I cut&paste that
paragraph to another location in another document? Must I preserve the
xml:id which may conflict with another xml:id? If I don't, is that
failing to preserve the xml:id? Those are just two really obvious cases
that come to mind and there are others.
The problem with specifying preservation in general is that it means you
have to define what that means for processing models, which isn't
something that ODF has ever done. It defines a document format, not how
you process it.
Noting that defining an environment in which an editor exists is
fundamentally different from that of a regular XML processor. A schema
or DTD can define xml:ids and it is straightforward to give the rules
for xml parser because it is never going to change or edit the text.
That is not the case with an editor. The reason why editors exist is to
change the text and to do so, they have to have a certain amount of
flexibility.
If you want to offer some constructive suggestions on how to deal with
this issue I am sure everyone would be interested. However, jumping up
and down and saying that xml:ids must be preserved isn't helpful. It
really doesn't matter how much you want that to be the case if you can't
offer any reasonable way for a standard to require it.
I would certainly prefer the preservation option but at this point I
can't see any useful way to make that a requirement without specifying
how ODF processors must work. And so far as I can tell, that is not the
purpose of the ODF standard.
And that is directly applicable to broken solutions for conversion that
rely upon foreign elements and attributes. There never has been any
requirement in ODF that foreign elements and attributes be preserved and
the authors of such methods knew that when writing their converter. The
authors of other software are under no obligation to make changes in
their software to work with such a solution. And using standards to
force others to adapt to a particular conversion strategy is extremely
poor standards making.
Does any of that help?
Patrick
marbux wrote:
>
>
> On 7/2/07, *Patrick Durusau* <
> <mailto:>> 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
> <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.
>
>
--
Patrick Durusau
Chair, V1 - US TAG to JTC 1/SC 34
Acting Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
Co-Editor, OpenDocument Format (OASIS, ISO/IEC 26300)
