My earlier response to Michael for more context ...
Begin forwarded message:
> On Jun 29, 2007, at 10:06 AM, Michael Brauer - Sun Germany - ham02 -
> Hamburg wrote:
>
>> 1. We have to make sure that the language we are choosing is precise,
>> and permits reasonable edit operations on documents. Related to
>> xml:ids, that means that the language must permit to remove the
>> attribute or to change its values if this happens as the result of a
>> user action or a machine processing the document.
>
> Right.
>
>> 2. If a document is opened and saved again, we all expect that the
>> paragraph content is preserved. The same applies to tables, lists,
>> images. etc.
>
> Does this include attributes?
>
>> Does the specification has a language that enforces
>> that? No, it doesn't. But we all expect that these features are
>> preserved anyway.
>> But what's different with the xml:id (and metadata in general) that
>> there is the assumption that it may get removed unless there is a
>> language that forbids that?
>
> 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.
>
> ...
>
>> 3. The focus of ODF of course are office documents. But there always
>> was the assumption that also other kind of applications should be
>> able to use ODF. So, if someone develops a small text editor and
>> wishes to support ODF to the extend that typical text editors can,
>> this should be be possible. Our language should not prohibit that. We
>> should also not forget the various ODF plug-in efforts for MS Office
>> or similar ODF implementations. They have only limited control of
>> what happens with certain information during complex load, edit and
>> save operations within MS Office. I'm not sure if they can preserve
>> all metadata and all xml:ids under all circumstances in a way that
>> keeps the metadata consistent and therefore of value.
>
> Well, let's say an application doesn't care about metadata. All they
> have to do is preserve the files in the package and the xml:ids as is.
> They need not do any kind of processing.
>
> I don't see how this is any real burden (?).
>
>> Having that said, here are my suggestions. Please do not consider
>> them as a proposal. They are only suggestions, and the SC may follow
>> them as a whole or partially, or may not.
>>
>> 1. We may move all the metadata related should/shall language into
>> the general conformance section. This has the advantage that it is
>> not overlooked as easy as it would be if it is in the element and
>> attribute description. It further has the advantage that metadata is
>> mentioned at a very prominent position.
>> 2. We may introduce the term of a metadata-aware application (or
>> something like that), and define conformance definitions along the
>> following lines for it:
>
> I think the rules should apply to all ODF 1.2 compliant applications.
> Carving out a separate category of "metadata aware" leaves a large
> loophole.
>
> On that basis, perhaps option 1 is preferable, where the language
> remains "shall." I'd go even further, n fact, and require preservation
> of all attributes. That makes it a generic requirement that is not
> specific to metadata, but ensures xml:id preservation.
>
> Bruce
>
>> - A metadata aware ODF implementation *shall* not remove the xml:id
>> attributes defined in sections [?] or change its values unless the
>> removal or modification is the result of an edit operation caused be
>> the user, or a similar action taken by some automatic processing of
>> the document.
>> - [any other requirement that may exist]
>> 3. We may rephrase the above statement for general ODF
>> implementation, replacing the *shall* with a *should*:
>> - An ODF implementation *should* not remove the xml:id attributes
>> defined in sections [?] or change its values unless the removal or
>> modification is the result of an edit operation caused be the user,
>> or a similar action taken by some automatic processing of the
>> document.
>> 4. Some time ago we have discussed whether the question which
>> implementation should/shall support what features may be a topic for
>> ODF 1.3. So we may go with no or only a very limited number of
>> metadata related conformance requirements for ODF 1.2, and make a
>> deeper discussion part of a more general discussion for ODF 1.3.
>>
>> Maybe these comments and suggestions are somehow useful.
>>
>> Best regards
>>
>> Michael
>>
>>
>> Bruce D'Arcus wrote:
>>> Svante,
>>> I suggest these go to the main TC list. This one, in particular ...
>>> On 6/27/07, Svante Schubert