Re: [office-metadata] final updates

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

So the TC approved the metadata proposal in principle today (great!).
We just need to do the remaining changes. I expect Svante and/or
Patrick will do this with a change-tracked version of the submitted
proposal.

Here's what I suggest:

1) I was fine with all editorial suggestions Svante posted, except for
the ones about preservation of attributes and files. I'll deal with
that issue below, but suggest we just make the other changes. That gets
us 98% or so to done.

2) I suggested requiring xml:id on text:meta-field. I can't really
think of any reason not to require it. Is that OK? This would require a
schema change (see TC list post).

3) On preservation of xml:id:

I agree after the lengthy discussion on the main list and on the call
today that this is a really tricky issue to define with any sort of
precision that actually achieves what we want to achieve without
unintended consequences. I would thus be fine with the following
language:

"All implementations SHOULD preserve any xml:id attribute and its value
when present on any of the elements listed in 1.4.3. If an applications
changes an xml:id attribute value, it SHOULD update any associated
bindings in the metadata manifest to maintain referential integrity."

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

I do not understand where you get the idea that SHOULD requires conformance unless there's an explicit reason not to do so. Here is the relevant definition:

>>>

The verbal forms shown in Table G.2 shall be used to indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a
certain course of action is preferred but not necessarily required, or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.

Table G.2 — Recommendation
Verbal form

Equivalent expressions for use in exceptional cases
(see 6.6.1.3)

should
it is recommended that
ought to

should not
it is not recommended that
ought not to

In French, do not use "devrait" in this context.

<http://72.14.253.104/search?q=cache:DxJI76h9l8QJ:www.iec.ch/tiss/iec/Directives-Part2-Ed4.pdf+Annex+H+of+ISO/IEC+Directives&hl=en&ct=clnk&cd=3&gl=us >, pg.61.

<<<

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>

<<<

We might want something similar for the metadata attributes (m:about,

etc.).

4) on the non-modification statement:

"Metadata files should not be modified unless the content of the
metadata file is changed."

Same criticism.

Svante suggested dropping it altogether. I'd like something like this
instead:

"All implementations SHOULD preserve metadata statements and their
associated RDF graphs stored in the file package."

Same criticism.

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.

office-metadata message