hey svante, this is great. can you talk a little bit about how this is related to an expanded bibliographic function? and/or about timeframes for various implementations bits?

thanks,

matt

Posted by matt price on October 12, 2007 at 09:21 PM CEST #

This does sound like a very important feature to get into ODF. Thanks to all the committee members for the time and effort to develop the spec.

Is there likely to be a big delay before OOo will be ready to handle files that use ODF 1.2?

Am I correct that OOo provides no UI for this, so the only way to access the metadata is through tools or extensions apart from OOo?

Has there been any planning as to what kind of UI (if any) that OOo might expose?

Posted by 69.248.236.96 on October 12, 2007 at 11:37 PM CEST #

Hello Svante:

this seems like a very important feature which many people have been asking for (especially in the area of custom schema support within openoffice, which this feature would address in many ways). What would happen to the exisiting metadata mechanism based on UserDefinedAttributes ?

thanks
ashok

Posted by ashok on October 13, 2007 at 09:11 AM CEST #

Will it support things like multi language metadata, multi language template names, fileds?

KAMI

Posted by Kami on October 13, 2007 at 12:28 PM CEST #

Hi, Svante,

Rather than gushing over the possibilities, it would be more helpful if Sun were to speak to how OOo 3.0 is going to handle RDF metadata created by non-Sun applications. Under precisely what circumstances will Sun's apps destroy RDF metadata created by other applications? As you well know, this was an enormous issue on the TC, as was acknowledged by Bruce d'Arcus:

"The bottomline is, because we move so much of the RDF logic into the package, the xml:id attributes become crucial anchor points. In short, if an application removes, say, the xml:id from a text:meta-field or otherwise causes the URI binding to be invalid, the field will break. ***It would be bad for interoperability for applications to do this."***

<http://lists.oasis-open.org/archives/office/200708/msg00042.html>.

As the person who proposed that conformant ODF apps be allowed to destroy RDF metadata created by other applications, both Sun and you personally owe the world an explanation of the circumstances under which your company's products will destroy such metadata. I previously called for use cases to expose any need to do so. The only response I received was the use case of a user-initiated action, which could have been handled under a "shall preserve ... unless" grammatical construct rather than the permissive "should preserve" that you proposed and that was adopted by the TC with the only remaining justification to allow for unforeseen circumstances. See my post linked above for a summary of what happened on the TC and Metadata SC, with links to the relevant other posts.

Specifically, if we use RDF metadata in our MS Office plug-in to establish lossless interoperability between MS Office and ODF applications, would Sun's applications preserve the RDF metadata our plug-in creates for that purpose so the interop can work in both directions? See <http://opendocument.foundation.googlepages.com/home>. Please address your answer in the context of ISO/IEC JTC 1 Directives, which require that standards "specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." <http://www.jtc1sc34.org/repository/0856rev.pdf>.

If you continue to evade such questions, why should the world regard as benign Sun's motives for the change in the ODF RDF metadata preservation requirements?

Posted by Marbux on October 13, 2007 at 08:03 PM CEST #

Hi, Bruce,

Did you have in mind Rob Weir's post at http://www.robweir.com/blog/2007/10/cracks-in-foundation.html (?) The one where he responded to my comment by saying in part:

"As for conformance clauses, this is a fair point. OASIS recognizes the need for formal conformance clauses, and as of this summer all OASIS standards, even those not going to ISO, will require a formal conformance clause. So this is something we will need to write up for ODF 1.2. The contents of such a clause is a good thing to be debating in the TC, or even publicly."

Just as long as its not Sun Microsystems staffers or Bruce d'Arcus participating in the debate, right? Heaven forbid that the chair of the OOo Bibliograhic project should actually talk about ODF interoperability conformance requirements.

Loved your line about "we need to start implementing the support before we can know all the little details that might crop up in that process." It speaks volumes about where you're coming from. It all gets worked out between you and Sun, right? No other developers get a clue except by looking at the OOo source code. None of that nasty talk about interoperability conformance requirements in the ODF specification.

But in my world, developers implement *standards* with mandatory conformance requirements rather than standards being a blank check for the developer with the biggest market share to break interop with other developers' implementations. We wanted to implement high fidelity round trip ODF native file support in MS Office, which has the troubling potential to make MS Office the market leading ODF implementation and break Sun's death grip on ODF. What can I say? ISO/IEC Directives are on our side, not yours or Sun's. The more you guys stand silent when violations of the Directives are brought to your attention, the worse your position is going to look when the coming battle at ISO over ODF 1.2 takes place.

And I'll note that my promise of litigation came after more than a month of refusal by anyone on the ODF TC to discuss our high fidelity round-trip business process and migration use cases and a long history of Sun's abuse of the TC to break high fidelity interoperability, both with MS Office and among ODF applications. It was your evasion of the technical issues that caused the promise of litigation; this isn't a philosophical question of whether the chicken or the egg came first. As the U.S. Supreme Court said:

"Typically, private standard-setting associations, like the Association in this case, include members having horizontal and vertical business relations. See generally 7 P. Areeda, Antitrust Law § 1477, p. 343 (1986) (trade and standard-setting associations routinely treated as continuing conspiracies of their members). There is no doubt that the members of such associations often have economic incentives to restrain competition and that the product standards set by such associations have a serious potential for anticompetitive harm. See American Society of Mechanical Engineers, Inc. v. Hydrolevel Corp., 456 U.S. 556, 571 (1982). Agreement on a product standard is, after all, implicitly an agreement not to manufacture, distribute, or purchase certain types of products. Accordingly, private standard-setting associations have traditionally been objects of antitrust scrutiny. See, e. g., ibid.; Radiant Burners, Inc. v. Peoples Gas Light & Coke Co., 364 U.S. 656 (1961) (per curiam). See also FTC v. Indiana Federation of Dentists, 476 U.S. 447 (1986)."

http://laws.findlaw.com/us/486/492.html (reinstating jury award of treble damages under the Sherman Act). You're the one who made the decision to climb into bed with Sun, Bruce when you decided to give ground on the metadata preservation requirement despite recognizing that it was an anti-interop decision. It's easy to discard antitrust conspiracy law as "ridiculous conspiracy rhetoric" outside of court. It's not so easy once things wind up in court, especially when you play outside rules requiring interoperability. As the Sun-backed European Committee for Interoperable Systems said:

"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 you and Sun did to ODF 1.2 RDF metadata was unquestionably anti-competitive, striking at the very heart of well-defined antitrust law on what is permissible in private industry standard setting organizations. So prove me wrong, and ask Svante to disclose how Sun's applications will handle the relevant preservation of RDF interoperability metadata issue. If you do not, your silence *is* the message.

Posted by 71.236.214.69 on October 13, 2007 at 10:47 PM CEST #

Bruce, before you changed your mind without ever offering a technical justification, you said yourself:

"I'm cc-ing this to the main TC list, because I think this question
about interoperability is critical to ODF; it's not just about the new
metadata support.

"The question is, what should the language be on preservation of xml:id
attributes in ODF 1.2. The xml:id attributes are critical to the
metadata proposal, but they could also be used for other purposes.

"The current proposal says they 'shall' be preserved. Michael and Svante
have suggested this be changed to the weaker 'should' or perhaps to
introduce some notion of 'metadata aware' ODF applications (effectively
a loop-hole).

"My position is that if we change it, we should make it a general
requirement to preserve attributes. We cannot allow applications to
arbitrarily throw out critical attributes."

"...

"... Preserving files and attributes is a trivial requirement. Not doing so will introduce large compatibility problems.

"Really, just to be clear: if applications do not preserve xml:id
attributes, fields will break, and any metadata about document
fragments will be made invalid. Is that really in anyone's interest?
They need not support metadata in any explicit way to do this."

http://lists.oasis-open.org/archives/office/200706/msg00125.html

The *only* use case for destruction of the metadata raised by anyone was as a result of a user-initiated edit. I proposed in response: "So thus far, we have "SHALL preserve unless destroyed through user-initiated action. Any other use cases that require exceptions?" http://lists.oasis-open.org/archives/office/200707/msg00024.html

And now you suggest that *I* should come up with the use cases exposing the need to destroy RDF metadata? You and your compatriots who railroaded this change through rapid-fire votes on the SC and TC are the ones who need to justify your proposal, not me. As the ISO/IEC JTC 1 Directives say, standards must "specify clearly and unambiguously the conformity requirements that are essential to achieve the interoperability." http://www.jtc1sc34.org/repository/0856rev.pdf (.) You are the guys who have to defend what you got through the TC, not me. My proposal to handle the situation by retaining the "SHALL preserve" language with itemized exceptions was ignored, just as the high fidelity interop use cases involving Microsoft-bound business processes and migration to ODF were ignored.

As to your suggestion that my method must account for applications that do not support metadata, we've been all over that on the TC and metadata SC. You deliberately conflate feature support with metadata preservation, which are two separate concepts. Here is Patrick Durusau's essay on the subject. http://lists.oasis-open.org/archives/office/200706/msg00137.html (.) As you said yourself, "[p]reserving files and attributes is a trivial requirement." And the choice is stark: between one-way and round-trip interoperability. The fact that one application does not need particular metadata does not mean that the next app in the processing chain does not.

In short, you are arguing with your own prior statements, not with me. But neither you nor anyone else have come forward with a technical justification for your change in position.

Your attempt to justify what was done by stating that "ALL the main implementors held this position" does no more than illustrate the problem. Standards to not exist to fortify the market positions of entrenched market leaders. They exist to encourage competition, including that from other developers. In our case, we wanted to add native file support for ODF to MS Office with our plug-in, with high fidelity conversions between the Microsoft legacy binary formats and ODF. We pulled it off, but we can't interoperate with OOo because OOo trashes metadata needed for the return trip. You helped close off another interop route by allowing Sun to trash RDF metadata.

Short version: international standards aren't just for the folk who already have implementations. They are for the world. OOo source code is not supposed to be the ODF standard. You envision a process where the entrenched implementers work out interop issues in private. That is not the way international standards work, as the ISO/IEC JTC 1 Directives testify. And as the U.S. Supreme Court has held, that's not the way any standards body located in the U.S. is supposed to work.

Posted by Marbux on October 14, 2007 at 02:44 AM CEST #

Svante, I encourage you and your ODF colleagues to consider participating in AIIM's Interoperable Enterprise Content Management (iECM) committee. I have agreed to lead a task team under the auspices of the iECM committee to identify existing standards and, as necessary, specify additional XML tags for all of the elements of metadata conceptually listed in ANSI/AIIM/ARMA TR48-2006. It would be good if those metadata were implemented in ODF.

Owen Ambur
Co-Chair Emeritus, xmlCoP
Co-Chair, StratML CoP
Member, FIRM Board
Member, AIIM iECM Committee
Former Project Manager, ET.gov

Posted by Owen Ambur on December 10, 2007 at 05:05 AM CET #