@Patrick, Very well, I would say merely that "producers may but need not preserve the same xml:id on elements that persist from consumption to production, so long as references to the element by IDREF continue to agree with the xml:id ID value. The alternative is to leave it the same as OF 1.2 does, which is to say nothing about xml:id ID-value preservation.

@Patrick: Are we saying anywhere else that the mechanism that an application chooses to fulfil a requirement of the standard is "implementation dependent"? I thought we used that language only for user visible behaviour.

@Andreas, if you read the conformance requirements for ODF Consumers, support for any feature is implementation-dependent. Basically the only requirement is to accept schema-conforming documents. There is no requirement to support any particular features in those documents.

I don't think there has ever been any consideration of implementation-dependent and implementation-defined provisions with respect to how users become aware of them or even notice, although there surely are ways that an allowed implementation-dependence would become apparent.

In the case of preservation of xml:id ID values, a failure to preserve them would likely show up in the case of the element being identified via its xml:id in RDF and the document producer preserved but did not coordinate the RDF with the document.

Users can be aware of URIs that refer into ODF documents via identification of fragment or into [X]HTML into exports of ODF documents, but these cases are not covered by the specification.

Individual implementations might do something about RDF and HTML Export stability, but what they do for both cases is highly implementation-dependent and there is no basis in the specification for expecting interoperability. I suspect that is a greater issue for RDF parts and for RDFa in the documents than anything else. It is of course the nature of RDF that a producers does not necessarily have a way of determining all of the ways a document element having an xml:id may be the subject of an RDF triple that exists somewhere.

Discussed Oct. 3, 2016 - would introduce a requirement not supported by gnumeric. - quite possibly other ODF applications.

Lack of fixed ids impacts interoperability.

XML:IDs could be created only on export - making other applications slower -