On 6/29/07, Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@sun.com> wrote:
first of all, it is my understanding that the issue that Svante is
raising here regarding the usage of shall and should is not that
applications should get the freedom to remove the xml:id and other
metadata features whenever they like. Of course, they should keep them
whenever this is possible and appropriate.
When is it impossible and inappropriate? Svante already announced during a Metadata SC call that Sun does not intend to support the entire Metadata proposal on the rationale that the market should decide which metadata features should be supported. That is the same excuse he gave for removing the requirement of xml:id attribute preservation. However, the market has already spoken on this subject. "No incomplete implementations, no proprietary extensions[.]" <
> (PDF, slide 7).
If you believe that there are valid reasons for destroying xml:id attributes, please present your use cases and draft a "SHALL preserve *except* when ...." replacement sentence for consideration.
The issue is to find an appropriate language for the things we want to
achieve. And independent of the issues we are discussing here, this in
general includes the option to omit a certain language if we believe
that what we say may be self-evident or given anyway, so that the
language is not required at all.
I disagree. If ODF is to become an interoperable format standard we must have conformance requirements for interoperability. For example, I am told that Sun's applications destroy all foreign elements and attributes other than paragraphs and text spans. That despite it being "self-evident" from an interoperability standpoint that all foreign elements and attributes necessary for interoperability purposes should be preserved. And also despite the fact that in ODF
1.0 the RFC 2119 definition of MAY made it mandatory that Sun do so. Sun's destruction of foreign elements and attributes has posed incredible difficulties in the Foundation's efforts to establish non-lossy interoperability with Microsoft Office. Difficulties that the Foundation had planned to work around using the Metadata SC's work. But now Sun seeks permission to destroy xml:id attributes as well. Why should it matter to Sun if it plans to preserve xml:id attributes anyway? The only justifications offered are flimsy beyond any credibility.
So please tell us unambiguously why it is so important to Sun that applications be allowed to destroy xml:id attributes, so important that we must be bothered with this request. And please do tell us straightforwardly whether Sun intends to implement the entire Metadata SC proposal. Was Svante telling us the truth?
Below are few suggestion that may or may not be helpful for addressing
the metadata related should and shall issues. But before. I would like
to make some comments:
1. We have to make sure that the language we are choosing is precise,
and permits reasonable edit operations on documents. Related to xml:ids,
that means that the language must permit to remove the attribute or to
change its values if this happens as the result of a user action or a
machine processing the document.
Agreed on user-initiated actions. But I disagree on removal of the attribute by a "machine processing the document." That is so ambiguous as to permit the wholesale stripping of the attributes for no reason at all, much as Sun's applications strip most of the foreign elements and attributes.
2. If a document is opened and saved again, we all expect that the
paragraph content is preserved. The same applies to tables, lists,
images. etc. Does the specification has a language that enforces
that? No, it doesn't. But we all expect that these features are
But so long as we do not require their preservation, we leave the door open for a developer to destroy them and still claim conformance, as Sun does despite its destruction of foreign elements and attributes. Europe has this to say, "Conformance testing and document validation possibilities
are needed -> in order to facilitate mapping / conversion." See slides linked above.
Right now, an empty Zip file is a conformant ODF document. I guess that makes the conformance testing easy, right?
But what's different with the xml:id (and metadata in general) that
there is the assumption that it may get removed unless there is a
language that forbids that?
Those who do not learn from history are doomed to repeat it. The Foundation has learned the hard way that Sun will destroy whatever metadata is necessary to block the Foundation's plugin from providing high fidelity interoperability with MS Office. We will be proposing several other requirements to prevent such misbehavior. And if they are not implemented in ODF, they will be implemented in our fork of ODF and will have center stage in our opposition to ODF
1.2 at ISO, in support of our request that this TC be required to fix the specification before ISO adoption.
I personally believe that everyone who is interested in ODF is
interested in implementing as much of ODF as possible (though there may
of cause be resource or technical restrictions), and this includes
metadata, regardless what language we use for above features.
Then please explain why: [i] Sun destroys foreign elements and attributes; and [ii] Svante said Sun does not intend to fully implement the Metadata SC proposal.
believe that we encourage more vendors to implement metadata if we talk
about the value of implementing them, than we do by making certain
things mandatory. For that reason, and because it seems not to be too
easy to find an appropriate language, it would be okay for me if we
would omit that language at all.
May I suggest that you begin by talking to your own staff about fully implementing the Metadata SC proposal? And about preserving foreign elements and attributes? In the meantime, it is unacceptable that Sun retain the discretion to break interoperability with other apps, so we will press for conformance requirements that Sun so richly deserves.
3. The focus of ODF of course are office documents. But there always was
the assumption that also other kind of applications should be able to
use ODF. So, if someone develops a small text editor and wishes to
support ODF to the extend that typical text editors can, this should be
be possible. Our language should not prohibit that.
Unless we add conformance requirements for the preservation of metadata and processing instructions, the less featureful apps will never be able to round-trip documents with the more featureful apps. Our language should require that. Personally, I believe that the software-as-an-end-point client-side office suites are dinosaurs at the end of their era. They are being finished off by a thousand cuts as users spend less and less time using them and more and more time using other apps, such as web apps. ODF either develops methods for interoperability among all apps or it will die along with the office suites.
E.g., Microsoft knows this and is busily migrating its Office development budget across the Sharepoint/Exchange server hubs to the network. Meanwhile, this TC fiddles with preserving the 1995 software-as-an-endpoint vision.
We should also not
forget the various ODF plug-in efforts for MS Office or similar ODF
implementations. They have only limited control of what happens with
certain information during complex load, edit and save operations within
MS Office. I'm not sure if they can preserve all metadata and all
xml:ids under all circumstances in a way that keeps the metadata
consistent and therefore of value.
And this speculation is a reason for allowing the destruction of metadata and xml:id attributes? Why don't you ask their developers?
Having that said, here are my suggestions. Please do not consider them
as a proposal. They are only suggestions, and the SC may follow them as
a whole or partially, or may not.
1. We may move all the metadata related should/shall language into the
general conformance section. This has the advantage that it is not
overlooked as easy as it would be if it is in the element and attribute
description. It further has the advantage that metadata is mentioned at
a very prominent position.
+1. That is precisely what I advocated on the Metadata SC. But there are far more areas of the specification requiring similar treatment.
2. We may introduce the term of a metadata-aware application (or
something like that), and define conformance definitions along the
following lines for it:
- A metadata aware ODF implementation *shall* not remove the xml:id
attributes defined in sections [?] or change its values unless the
removal or modification is the result of an edit operation caused be the
user, or a similar action taken by some automatic processing of the
- [any other requirement that may exist]
We have been discussing something similar for some time. We see a need for two conformance classes: [i] fully integratable software qualified as routers of information in business processes; [ii] software that qualifies only as an end point solution. The latter would be for legacy ODF apps and ODF apps whose developers are satisfied with one-way interop with applications that have different feature sets and would have minimal conformance requirements and most likely would not qualify for government software procurement tenders. The routers of information class would have strict conformance requirements as to interoperability features such as preservation of metadata and processing instructions. This class would attempt to satisfy, as closely as is feasible, the European Open Document Exchange Formats requirements, which incidentally calls for convergence of the Microsoft and ODF formats, with ODF providing the common functionality.
But again, please be less ambiguous about "a similar action taken by some automatic processing of the document." That reads like a signed cheque with the amount to be filled in left blank.
3. We may rephrase the above statement for general ODF implementation,
replacing the *shall* with a *should*:
- An ODF implementation *should* not remove the xml:id attributes
defined in sections [?] or change its values unless the removal or
modification is the result of an edit operation caused be the user,
Change that "should" to "shall" and we might find agreement. "Should" is meaningless in the ISO requirements keyword definitions. It is a license for abuse.
similar action taken by some automatic processing of the document.
Again, this needs more detail. We can not support language so ambiguous.
4. Some time ago we have discussed whether the question which
implementation should/shall support what features may be a topic for ODF
1.3. So we may go with no or only a very limited number of metadata
related conformance requirements for ODF
1.2, and make a deeper
discussion part of a more general discussion for ODF 1.3.
From our perspective it would be better to aim for doing the job in ODF 1.2, even if that requires delay. We will oppose ODF
1.2 at ISO unless the interoperability warts are cleaned up. What the market requires is no longer in doubt. See the slides linked above and further presentations linked from this page, <
>. Substantial progress toward those goals would seem to be mandatory to maintain Europe's preference for a harmonized set of file formats that uses ODF to provide the common functionality. Delaying commencement of such work enhances the likelihood that governments will tire of waiting for ODF to become interoperable with MS Office and simply go with MOOXML. We may not be able to force Microsoft to participate in the harmonization work, but we will be in a far better position if we have done everything we can in aid of that interoperability without Microsoft's assistance.
As the situation stands, we have what is known in the U.S. as a "Mexican stand-off," where neither side has taken a solitary step toward what Europe has requested. We have decided to do that work via a fork of ODF; it is up to this TC whether it wishes to cooperate in that effort.