Re: [office-metadata] final updates

[marbux <marbux@gmail.com>]

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

On 7/2/07, marbux <marbux@gmail.com> wrote:

...

>  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?
>
> >>>
> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
>  may exist valid reasons in particular circumstances to ignore a
>  particular item, but the full implications ***must*** be understood and
>
>  carefully weighed before choosing a different course.
>
> <http://www.ietf.org/rfc/rfc2119.txt >
>
> <<<

I am meaning something like the above.

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.

...

> > That's not quite right, but I can't think of anything better. It at
> > least gets away from worrying about the specific structure of the
> > files, and focusses on the content, and it make implementors aware of
> > the issue even if they don't implement metadata support.
> >
>
> You are giving away an interoperability conformance requirement, Bruce.

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

Why? Did I miss a use case?

For what it's worth, I'll throw out for discussion a different approach used by XML 1.0 for preservation of white space. Would it be useful to adapt that approach to preservation of xml:id attributes?

>>>

A special attribute named xml:space may be attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other, MUST be declared if it is used. When declared, it MUST be given as an enumerated type whose values are one or both of "default" and "preserve". For example:

<!ATTLIST poem  xml:space (default|preserve) 'preserve'>

<!ATTLIST pre xml:space (preserve) #FIXED 'preserve'>

The value "default" signals that applications' default white-space processing modes are acceptable for this element; the value "preserve" indicates the intent that applications preserve all the white space. This declared intent is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of the xml:space attribute. This specification does not give meaning to any value of xml:space other than "default" and "preserve".

http://www.w3.org/TR/REC-xml/#sec-white-space (portions of section omitted).

<<<

See also the XSLT Recommendation, section  3.4 <http://www.w3.org/TR/xslt#strip > (similar).

The thought here is that xml:id attributes needed for interoperability could be tagged as such and implementations required to preserve them.
 

The metadata proposal has gotten to its final (I think quite sound)
state through a lot of hard work at consensus building in this
committee. The final product is in fact a reflection of that
collaborative work.

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.

Getting a commitment from them to do the right thing about preserving foreign elements and attributes would be a confidence builder. :-) 

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

Why do you think they want the discretion to destroy the xml:id attributes? The only explanation I recall was that beyond-flimsy "let the market decide" excuse.

And has Sun recanted Svante's previous announcement that Sun does not intend to fully implement the metadata SC's work, again on the excuse that the market place should decide what is useful? I am genuinely curious whether Sun has changed its position on that. 

My concern is that "SHOULD," whether defined with the RFC or the ISO/IEC definition, allows an implementation to destroy any or all xml:id attributes and remain a conformant application. Whether a developer destroys the attributes because of malice, laziness, or lack of understanding, the result is an ecosystem of documents being exchanged in which users can have no confidence that data will not be lost in the exchange. 

And the fact that the developer with the lion's market share uses the specification's present permissiveness to destroy foreign elements and attributes and now seeks permission to destroy other information required for interoperability is not a situation in which I am confident your hopes will be realized.

I would be far happier with dual classes of conformance, one for developers content with their applications being end point solutions and a second class for applications that are designed as high fidelity routers of information. The latter class would have far more strict round-tripping requirements. Both classes would be required  to include meta information in documents identifying which class of application last saved the document. That would enable the router of information class of applications to warn users when they load a document saved by an end point solution that data may have been lost. 

And such warnings would give developers of the end point solutions reason for becoming developers of information routers, as they get feedback from their users, so there is an incentive for interoperability built into the approach. 

The TC may blind itself to the problem, but it was the inability to integrate OpenOffice.org with Microsoft-bound business processes in Massachusetts agencies that forced ITD to approve OOXML as an "open" format for use in that state's executive branch agencies. See <
http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9026082>. Interoperability matters. As the maintainer of the OpenDocument Fellowship's page that tracks ODF government adoption decisions worldwide, <
http://opendocumentfellowship.org/node/91>, I can say without reservation that we have won many adoption decisions but have darned few implementations to show for it. Nearly all implementations have been in new government programs or programs with low data retention requirements such as school programs. Denmark was the first to break from the ODF fold, permitting both ODF and OOXML. Now Massachusetts. The rest of the nations that are awaiting ODF interoperability are unlikely to await ODF v. 
1.3 as Sun proposes. Our adoption progress is faltering. 

The market requirement is clear: "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> (slide 8). 

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.