ODF 1.2 <draw:frame> is more complicated - a parable

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

In the conversation today, I had the presence to ask if it was <draw:frame> that provides a sequence of alternatives only one of which is rendered by a consumer.

The answer is yes.  So that makes it <draw:frame> an unlikely the-least-granularity-that-can-actually-work case for the granularity of draw-element change tracking, even though it is commonplace for the draw:frame to have exactly one child element.

There is a lesson here about the importance of addressing the ODF feature levels in considering how change-tracking can apply.

1. For example, ODF 1.2 Part 1 section 10.4.1, "each child element of a frame is a different representation of the same content.  The order of the content elements reflects the document author's preference for rendering, with the first child element being preferred.  That means that consumers should render the first child element that they support."

2. This is the kind of element where the ODF feature is itself problematic and it raises concern for collisions with cross-cutting global features.
 2.1 If one of the renditions is change-tracked, but that is not the one that is presented by a consumer, what is the user expected to know or deal with?
 2.2 If the overall document has been signed digitally, what problems does this (and the change-tracking or not) raise about what it is that is signed and what might be repudiated if the signer did not see the rendition that a consumer is presenting?
 2.3 There are considerations related to accessibility and which rendition is accessibility support associated with?  (Presumably a <draw:text> as the least-preferable rendition does not mean this is specifically for accessibility purposes.  It could be ASCII art for all we know.)
 2.4 There are also metadata issues having to do with RDFa markup in any change-tracked material and what happens when the RDFa is moved to a <text:changed-region> structure.  Also, how does one reconcile references into change-tracked material from a separate RDF+XML part of a package that relies on xml:id values in the material involved in a change.

3. While proposing bottom-up least-that-could-possibly-work approaches is not a bad thing, the other half of that is one have a way to fail early when the least is less than that, especially when it is clear that a do-over is needed, not an accumulation of exception cases ("More lipstick please!").  To know that, there must be some concern for the end-point situation.  In this case I think it has to do with understandability with regard to ODF features and the ways they bear on each other, especially global ones and ones that act from-a-distance as it were.

 - Dennis