Re: preserving metadata (was deadlines?)

[marbux <marbux@gmail.com>]

On 5/13/07, Bruce D'Arcus <bruce.darcus@opendocument.us> wrote:
> I'm not clear what you're objecting to. Is it this sentence?
>
> "The attribute xml:id may occur on the following OpenDocument elements:"
>
> Would it be resolved by adding an additional phrase?
>
> "Xml:id attributes shall be preserved, unless their containing element
> is removed." or some such?
>

Sorry for the delay getting back to you. It is that sentence that I am
focusing on. Your suggestion would cure part of the problem, although
I'll propose a different solution for that aspect.

But I'm also not clear on the intent of the sentence because the word
"may" is ambiguous in context. E.g., if the intent is to say that the
Xml:id attribute can *only* be used with the listed elements, that
isn't what "may" means in context. With that intent, we might better
say, "The attribute xml:id may occur **only** on the following
OpenDocument elements."

On the other hand, if the intent is that implementation of the Xml:id
attribute is truly optional, then we're into the issue of preservation
of the attributes because ODF lacks any definition for "may." My
concern here is that "may" has been interpreted by at least one vendor
as permitting the desctruction of elements and attributes that MUST be
preserved for interoperability purposes under the RFC 2119 definition
of "may." And if apps produce ODF that is non-conformant with RFC 2119
then their ODF is non-conformant with XML 1.0. So we have a data
preservation problem that is broader than just the Xml:id attributes.

For that reason, my suggested resolution on the preservation of the
XML:id attributes is to recommend to the TC that it amend the
conformance section to require: [i] that implementing applications
must produce XML that is conformant with the XML 1.0 ISO standard;
[ii] expressly make the definitions provided by RFC 2119 (incorporated
by XML 1.0) applicable throughout the specification; and [iii] place
an informative note where appropriate in the Metadata section and
elsewhere reminding that the definition of "may" in RFC 2119 requires
that implementing applications must be prepared to interoperate,
whether they support particular features or not, then note the
importance of element, attribute, and metadata preservation to that
requirement.

The reason I suggest taking that approach is that the entire
specification needs examination in light of that particular
conformance issue. I am concerned that the lack of definitions has led
to OOo producing ODF that is non-conformant with XML 1.0; e.g., OOo
does not destroy foreign elements and attributes required for
interoperability purposes, hence OOo is not conformant with the XML
1.0 standard.

In light of the need for remedial work in implementations whose
developers did not understand the XML meaning of "may," I suggest
reminders where appropriate that "may" allows elements and attributes
to be supported or not, but that applications MUST not destroy tags or
metadata necessary for interoperability purposes.

On the other hand, I'm not far enough into the Metadata SC work to
understand whether a requirement more explicit than that in RFC 2119's
definition of "may" is needed.

> The statement about preserving RDF/XML files is as follows:
>
> "An OpenDocument package may contain an arbitrary number of metadata
> files. The content of the metadata files shall conform to the [RDF-XML]
> specification. Applications that read and write documents should
> preserve all metadata files. Metadata files should not be modified
> unless the content of the metadata file is changed."
>
> Suggest how you would change it and we can talk about it.
>

How about changing "Metadata files *should* not be modified unless" to
"Metadata files *must* not be modified unless"? Is there any valid
reason to modify metadata files other than to change the content?

The concern here is that the definition of "should" in RFC 2119 is not
a model of clarity as to the degree of discretion it provides. For
that reason, I lean toward not using it in circumstances where the
mandatory "must" or "shall" more clearly conveys what is actually
intended as a requirement.

Best regards,

Marbux