Re: [office] OpenDocument TC coordination call minutes 2007-08-13

[marbux <marbux@gmail.com>]

On 8/13/07, Bruce D'Arcus <bdarcus@gmail.com
> wrote:

On 8/13/07, marbux <marbux@gmail.com> wrote:

> Why did you think Sun is so determined to retain discretion to destroy
> metadata xml:id atttributes?

First, this is of course a particularly biased interpretation of the
language of the metadata proposal.

So what is a use case for destroying the xml:id attributes other than by user-initiated action, Bruce? I've given you one, to destroy interoperability. And back when, I offered what Sun does with foreign elements and attributes as evidence that the concern was not far fetched. Surely you can provide a use case use if you  believe mine is "particularly biased."

 

You may recall that I was the one who first pointed out that the lack of a requirement to preserve metadata attributes raised an interoperability issue and that primarily you, Patrick, and I worked out language making their preservation mandatory. It was added to the Metadata proposal without objection.

Then Sun (Svante) popped out of the woodwork just before the SC work was to be submitted to the TC with a proposal that "SHOULD preserve" be substituted for "SHALL preserve," offering only a single justification that was flimsy beyond any credibility. < http://www.oasis-open.org/archives/office-metadata/200706/msg00049.html >.  ("Similar as other standards (e.g. CSS) we should not try to force features by specification, but should let the market sort this out.")

You responded:

"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://www.oasis-open.org/archives/office-metadata/200706/msg00066.html >.

So the interoperability issue was squarely raised; in fact, you were the first to raise it in response to Sun's proposal that StarOffice/OpenOffice.org -- or any other ODF 1.2 application -- be permitted to destroy xml:id attributes.

But you dropped your opposition to "should preserve" after a TC conference call where tentative approval was given to the SC proposal, saying

:

***"As we discussed,*** the language of "should" is already fairly strong, basically requiring conformance unless there's an explicit reason not to do so."

<http://www.oasis-open.org/archives/office-metadata/200707/msg00001.html
>.

So apparently the "consensus" you refer to below was that "should" requires conformance unless thre is an explicit reason not to do so. I responded:

"I do not understand where you get the idea that SHOULD requires conformance unless there's an explicit reason not to do so."

<http://www.oasis-open.org/archives/office-metadata/200707/msg00009.html
>.

In the same post I quoted and linked the relevant definition of "should" from the ISO/IEC Directive that is incorporated in the ODF specification, which takes the common and ordinary permissive sense of "should," then said:

"It says nothing whatsoever about conformance. And an implementation that ignores the recommendation is still conformant. Are you confusing the SHOULD definition that actually applies with the RFC 2119 definition of SHOULD?"

I then quoted and linked the RFC 2119 of "should," which does include a mandatory interoperability requirement, and closed with a warning:

"You are giving away an interoperability conformance requirement, Bruce."

In your response, you quoted the RFC 2119 definition of "should" from my post, and said:

"I am meaning something like the above."

...

I agree with the consensus that we cannot reasonably mandate preservation of xml:id or other attributes in the spec.
...

"I think in practice it'll work out quite fine. In the past couple of days I've seen public commitments from two major implementors to support the metadata proposal; I'm happy to work with them so they do the ***right thing*** on the details.

"If they do the wrong thing, they'll hear from me :-)"

<
http://www.oasis-open.org/archives/office-metadata/200707/msg00010.html
>.

To which I responded:

"If you mean the RFC 2119 definition, it's not in the ODF spec. Those definitions were removed in ODF 1.1 and replaced by the more lax ISO definitions, at ISO's request. So if you want something like the RFC 2119 definition of SHOULD to apply, you will have to add a specific definition. As I read the ISO/IEC directive, we do not have the discretion to go back to the RFC 2119 definitions generally, so it would need to be a special definition of SHOULD for the Metadata section. "

<http://www.oasis-open.org/archives/office-metadata/200707/msg00011.html

I again requested a use case exposing the need for destruction of xml:id attributes, and closed:

"I believe the high fidelity interoperability issue deserves far more strict attention in ODF v. 1.2  than it is being given. "SHOULD" does little for interoperability. It is merely an aspiration. Construction of a "SHALL ... unless" requirement may be more work, requiring the rooting out of the exceptional use cases, but it does far more for interoperability."

The point of this extended reminder of events is that in no way, shape, or form could it be argued in regard to the metadata SC's work that *conformity requirements that are
essential to achieve the interoperability,* within the meaning of the JTC 1 Directives, have been "clearly and unambiguously" specified. And the summary of relevant statements above is certainly understandable enough for press consumption. I will also add it to the antitrust brief I am preparing to send to the antitrust enforcement community, so you may get a chance to answer the hard questions you decline to answer here at your deposition.

Vague commitments by two developers to "fully support" the SC's proposal are not interoperability conformity requirements and says nothing at all about their intent in regard to preservation of xml:id attributes. Neither is your eagerness to help those two vendors do the "right thing" nor is your warning that they will hear from you if they do the "wrong thing." (As though their bean counters care.) 
May I also point out that this is supposed to be a specification for the entire world, not just for two vendors?

Second, this is not a Sun position. It's a consensus of the TC, and I
heard support for this from engineers from KOffice and IBM as well.
You weren't at that meeting, nor at any of the others, so I'm not
surprised by the oversight.

That's an unprincipled straw man argument, Bruce. I did not say this is a Sun position, albeit the record is clear that it originated as a Sun proposal. You've simply mischaracterized what I said to avoid discussing the substance of what I said. Your silence on the substantive issues speaks volumes about just how indefensible the SC's work will be at ISO and in the antitrust cases. And you are wrong about me never having attended any of the meetings.

Sun's "let the market decide" rationale and the never-explained difficulty in wording an exception to "SHALL preserve" for user-initiated actions are the only justifications for "SHOULD preserve" that appear in the public record. The supposed difficulty in wording an exception for user-initiated actions is totally at odds with your own statement that you will help two vendors do the "right thing." If the "right thing" can be coded in an implementation, the "right thing" can be described in human language as well. And Sun's "let the market decide" is just another way of saying Sun wants discretion to destroy xml:id attributes. 

And not just destroy xml:id attributes. All of the other mandatory preservation requirements that were in the SC proposal have suffered the same fate. Like I said before, you gave away an interoperability requirement, without so much as a use case exposing any need to do so. 

So I'll ask again, Bruce. Can you identify a single use case for destruction of xml:id attributes other than by user initiated action? At least some of the ISO national bodies will want to know. And if you can identify such a use case, please explain why it can not be adequately addressed by a "SHALL preserve  .... unless" grammatical construct. Such a construct "clearly and unambiguously" specifies "conformity requirements that are
essential to achieve the interoperability," while "SHOULD preserve" does not. 

I think it telling that you began this discussion by calling for less talk about "interoperability." You and others may not like the JTC 1 definition and associated interoperability requirements. But that dislike makes them no less applicable. The issue is really whether you want to deal with those issues here or at ISO, where Microsoft will have much more influence in the interoperability requirements, particularly if you and others on the TC send ODF 
1.2 off to ISO with a blank slate in that regard. My read of the situation is that if Microsoft can't live with what the ISO ballot ballot resolution process on Ecma 376 produces, ODF 1.2 will not have the smooth sailing at ISO that its predecessors had. And long before that you will certainly be facing our criticism. Indeed, you are already having to deal with it.  See your comments here. <
http://www.oreillynet.com/xml/blog/2007/07/can_a_file_be_odf_and_open_xml.html>.

Get ready for more. Your evasions motivated me to get around to documenting your own contribution to the ODF interoperability mess sketched above. We will be letting the world know about your role too.

Best regards,

Marbux