Requirement

[rjelliffe@allette.com.au]

+NAME
Rick Jelliffe

+CONTACT
rjelliffe@allette.com.au

+CATEGORY (select one or more from below)
import-export

+SCOPE (select one or more from below)
packaging/general

+USE CASE
Markup Compatability and Extensibility (for next generation ODF)

There is no difference between annotations provided using
element syntax, attribute syntax, in RDF, in bookmarks, in
extra files in the ZIP archive with exrernal markup, in application
settings, or in the several other mechanisms provided by ODF without
restriction, as far as their use for "embrace and extend" is concerned.

Consequently, merely restricting ODF by banning foreign elements
in the hope that this can prevent extensions is futile and tokenistic.

What is needed is a more systematic way by which foreign elements
and attributes  can express whether they are required or not. The
IS 29500 Part 4 Markup Compatability and Extensibility mechanism is
well-thought-out and useful.

This should be accompanied by clear conformance text, specifying that
at least one branch of all alternatives for data or metadata defined by
ODF should be provided in standard minimal ODF, regaradless of any
alternatives provided. It is this conformance
text rather than any schema that provides the guard against extensions;
there is no syntactic way to prevent extension data, unless the multitude
of alternative forms already allowed in ODF are removed.

Some specific use cases are:

1) a graphics program wishes to add annotational metadata about node
connection, based on its own history mechanism. It wishes to use
attributes, which are the most straight-forward mechanism.  MCE allows
these
attributes to be in a namespace that is marked as "not required".

2) a DOCBOOK application wishes to save as ODF but to keep as much
metadata as possible concerning DOCBOOK element hierarchy, so that the
document can be round-tripped as far as possible. (The application is
smart enough to cope with missing or moved elements, as might result from
some kind of editing in a different application: it is not a problem.)

3) a program such as Mathematica uses its own native format but can export
and import from MathML. Its native format uses substantially different
semantics in that it allows execution. The alternate section mechanism of
MCE allows the main section to be standard MathML, but with an alternate
section using the native Mathematica format. If the receiving application
is Mathematica (or an opens-source alternative), then it can open using
this information. If the receiving application is a vanilla ODF consumer
it can strip out the Mathematic alternative (or pass it through unchanged
if it is smart enough to detect that no editing has occurred on the
formula, but this is optional.)

4) a new version of ODF is created with some minor tweaks. MCE allows
markup for parallel sections that conform to the old and the new schema.

5) a program uses ODF but with its own custom extensions for data that
have no equivalent. Using MCE this can be clearly marked up, and the
document is clearly labelled as one in which use with a vanilla ODF
application will result in data loss. (And therefore unacceptable for
public standard data exchange, or for use in systems with
application-substition requirements, etc.)

+DESCRIPTION

Clone the OOXML IS29500 Part 4, mutis mutandi, removing OPC and
OOXML-specific references. Refer to OOXML IS29500 by reference as the
non-normative source. (Participation in converging the packaging of ODF
and OPC is a different, larger matter.)

See
http://broadcast.oreilly.com/2009/02/safe-plurality-markup-compatab.html
for a brief discussion of MCE.

See
http://broadcast.oreilly.com/2009/02/modus---minimum-open-documents.html
for a discussion of conformance text to prevent embrace and extend.