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


marbux wrote:
> On 7/2/07, *Patrick Durusau* <patrick@durusau.net 
> <mailto: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?
And how do you define "user-initiated action?" Does changing the content 
of the element count? What if I delete the content of a paragraph and 
insert an image, all without disturbing the xml:id? Does saving the file 
count as "user-initiated action?" Remembering that some implementations 
don't use ODF as a processing format but only for interchange.

Or were you planning on requiring the use of ODF as a processing format? 
Now that would be a radical change in the current standard.

All the current standard requires is that an application use the 
relationships and behaviors as defined by the standard for a document 
that it encounters and when it writes out a document that it use those 
relationships and behaviors to construct its files. What happens in 
between is not specified.
>     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?
Simply saying "shall" is not a suggestion. As I tried to illustrate 
above the question is more complex that you seem to realize.
>     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?
There is round trip interoperability for matters specified by ODF. That 
is paragraphs, styles, etc.

That is if you construct an ODF document as specified by the ODF 
standard, it will be read by another ODF application of similar 

What you seem to want is interoperability using arbitrary content 
between two or more applications. So far as I know, that has never been 
a goal of ODF, nor do I think it is possible.
>     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.
So, you would force all ODF based applications to preserve unknown and 
unknowable content in the name of interoperability?

If you send your file to my ODF application which doesn't understand 
your content, how is that interoperability? My application can't read 
it, can't change it, etc. How is that interoperability?
>     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.
RFC 2119 does not appear in the current version of ODF so is really 
irrelevant to this discussion.
>     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?
Let me say it back to you:

It is not possible to have interoperability based upon the premise that 
all ODF applications must accept unknown content. To use unknown 
content, ODF would have to specify how to handle unknown content, since 
unknown content that simply lies there really isn't useful to the 
application. And no, standards never include mandatory tools, but 
particularly ones that have failed in the marketplace. FYI, the notion 
of a tool designed for *any* conversion strategy is simply a fantasy. 
There are pattern matching languages that in theory can convert from any 
arbitrary format to another but those aren't tools in the traditional 
sense of the word.

> 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 
> <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.
Wait! You forgot the forth option offered by the Spoiler Party:

* Preserve foreign elements and attributes for the use of third part 
mediator applications to map between formats.

Which is the reason for wanting the "shall" on preserving foreign 
elements that are not used by any defined application. To support the 
Spoiler Party mediator.
> 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?
Use ODF. Assuming that the applications implement the same features. 
Noting that ODF does not require a particular set of features be 
supported in order to allow for a variety of ODF based applications. But 
that has nothing to do with preservation of foreign elements and 
attributes or even xml:ids.

I may have an application that doesn't support drawing, formulas, etc., 
but only adding metadata to a document. That can still be an ODF 
conforming application. But I really should not be using it if someone 
sends me a document to read and print.

The key phrase in the EU document that you overlooked was "must be 
possible without technical barriers." That does not mean that all 
applications have to implement the same set of features but merely that 
there is no "technical barrier" to my having an application with those 

Hope you are having a great day!


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)

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