Support the user with diverse ODF provisions

[jose lorenzo <hozelda@yahoo.com>]

Attributes belonging to the root element can be used to control conformance requirements. There is always going to be disagreement over what should define a conforming app or doc. Why not just let the creator of the document specify the rules for the document (restricted to ODF provisions). You want restriction X or Y on foreign elements? No prob. You don't? No prob. User rulz.

For example, an attribute preserve-foreign-content="true" can require conforming apps "editing" the document to keep all standard elements within a foreign tag. preserve-foreign-elements="true" can signify that everything be kept.

Instead of more top level attributes (along existing ones like office:version) to define the full semantics, the document can use top level elements which themselves could specify through attributes or child elements if the semantics applies to "editing", to opening the document for any purpose, or to specify any other finer grain semantics ("opening" might be considered a special degenerate case of some flavor of "editing").

As existing analogy, HTML has various "profiles" for conformance(?) and for document interpretation, eg, XHTML 1.0, HTML-trans, HTML 4.0. Here, the interpretation of the document depends on an attribute (if present) specifying which of these three cases defines the rules for the document.

An extension of this HTML analogy to include "editing" would then correspond to the scenario being described in this email.

We can apply this principle to many parts of the document, eg, to define conformance or to define something else for any part of the document. Foreign tags is just a particular recurring example on this list, but it's not the only possible use case (foreign tags description is found near the front of the standard and this helps it gets more "hits" throughout debates).

Hope this mini proof-of-concept example is found useful, despite being very short on detail.

I like the idea of giving as wide a range of users (use cases) as possible as much control as possible. The general idea described here shows that it's possible to come up with a compact solution to help include the needs of a greater number of users. Why favor only one group and make the others unhappy?

There are real interop issues to be considered with this approach that do not exist otherwise. In fact, is interop across ODF versions falling short of expectations? A framework can be produced to make moving forward a smooth process from the pov of interop. Before we advance too many ODF versions, there should be a solution in place. If there is one, could someone point it out? I haven't heard much talk over this and haven't read of it being addressed within ODF.