[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
+NAME Rick Jelliffe +CONTACT firstname.lastname@example.org +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.