Re: [office] Preservation question

[marbux <marbux@gmail.com>]

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

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.

So thus far, we have "SHALL preserve unless destroyed through user-initiated action." Any other use cases that require exceptions?
 

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.

I think that's an overstatement. E.g., the lists amendment seems to give fairly explicit processing instructions. But even were I wrong about that, the fact that something hasn't been done before is not a particularly strong argument for not doing it when needed. If it were, we'd still be living in trees and swinging on vines. :-) 

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.

Agreed. But the question at hand is not whether they should have flexibility but how much?
 

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've been offering suggestions. E.g., why won't "SHALL ... unless" work? Or the approach of hanging <preserve> attributes on those that require preservation for interoperability purposes?

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.

So no way to require round trip interoperability, eh?

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.

Unless conformance requirements mandate that they do so.
 

And using standards to
force others to adapt to a particular conversion strategy is extremely
poor standards making.

You know that we disagree on what the RFC 2119 definition of MAY required in ODF 1.0 so I will not address that anew, except to note that Gary and crew believed the TC would require the preservation of foreign elements and attributes in ODF 1.2. But King Michael has decreed otherwise.

Does any of that help?

I think it clarifies that you believe there is no way to *require* application interoperability in the ODF specification without specifying how ODF processors must work, that you oppose specifying how ODF processors must work for interoperability purposes, and that you oppose the standard including any mandatory tools designed for *any* conversion strategy.  Is that a fair summing up of your position?


Here is the market requirement, Patrick:

"For all parties involved, the exchange of
 documents and data between authorities,
 businesses and citizens must be possible without
 technical barriers."

<http://ec.europa.eu/idabc/servlets/Doc?id=27956>.

Here is what IBM/Sun/ECIS are saying ODF already does:

"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
>.

In the months I have participated on this TC, I have seen three methods of achieving round-trip interoperability discussed:

* 1:1 feature match between applications with accurate mapping between them.
*  Declared interoperability subsets with implementing compatibility modes in applications (a variant of the above method).
* Preservation of meta information required for interoperability by applications whether they support features or not.

By default, we have only the first method, which means in practical terms that we have in reality a de facto standard for the most featureful application disguised as a 

de jure standard. Long Live King Michael. ODF is little different from OOXML in that regard.

So here is a use case for you to solve:

Sally Secretary uses Brand X ODF editor. She receives a file from Suzy Supervisor who uses Brand Y 
ODF editor. Sally wants to make some edits and send it to lawyer Sleazy Sam, who uses Brand Z ODF editor. Sam wants to make some edits and send the document to Suzy for printing out and signing. All three don't want to have to worry about whether data will be lost during the three-way round trip.

I'll remind that the very reason for standards is substitutability of goods and that in the software context that means interoperability, as ECIS/IBM/Sun have so eloquently reminded us: 

"Interoperability is a cornerstone of the ICT industry. In today's networked ICT environments, devices do not function purely on their own, but must interact with other programs and devices. A device that cannot interoperate with the other products with which consumers expect it to interoperate is essentially worthless. It is interoperability that drives competition on the merits and innovation. The ability of different computer products to interoperate allows consumers to choose among them. Because consumers can choose among them, interoperable products must compete with one another, and it is this competition that has driven innovation in the software industry."

http://www.ecis.eu/inter/index.html    

What is *your* solution for Sally, Suzy, and Sam?