Dear TC members,
as briefly discussed in our last TC call, I would like to seek your endorsement for the following draft of an approach: Â Â
 Â
Currently, the only common denominator for ODF applications is the ODF XML, as it is the only standardized base of interoperability.
Unfortunately, only a few ODF applications are using the ODF XML at run-time, for instance in contrary to HTML which structure is being used as DOM at run-time in all its browsers.
Instead, ODF applications are loading (or filtering) the ODF XML into their optimized run-time model - a model being proprietary to each application - and only after editing saving ODF back to XML.
   Â
But for change-tracking, we are as well in need of a denominator at run-time to be able to track changes. Remember the TC decided once - as a result of the currently hibernating ODF collaboration SC - to allow efficient collaboration based on the idea of defining changes based on the reoccurring change patterns of the userâs editing. Opposed to explicitly declaring all XML changes - following the âconvention over configurationâ paradigm.
Nowadays, change-tracking does only save the previous state in general as a "black box" Âto reenable the previous state if the change is being rejected.
Â
But there is already some unspecified run-time structure, which is completely equivalent to XML nodes in our ODF XML grammar. There are clusters (or puzzle pieces) of some user's known entities defined by patterns - like <table:table> is marking the start of the ODF feature of a table.
In addition, there are also recurrent change patterns of users, for instance, the insertion of a 3rd new column within a table would result in the same document for all ODF applications.
A table, image, paragraph, etc. are examples for user known features, defining as abstract tree representation from our ODF XML, which also exists in all ODF applications during run-time.
We might call this abstraction an âODF feature treeâ or analogue to XML, the âODF INFO SETâ. These features are what users are used to add, modify and delete across all ODF applications.
There are in general two types of features:
* Structural features: like a table, image, paragraph or character and
* Behaviour features: non-existent for itself, but dependent on structure: like bold, background-colour, therefore, in general, all formattings and metadata.
As the ODF feature tree is directly derived from the ODF XML, there will be in the end a bidirectional non-lossy transformation from ODF XML grammar to the ODF feature tree.
Still, none of these features is mentioned yet explicitly in our specification.
To get an idea on how to start, we might begin to work on an "ODF Primer", which could be shared by all ODF applications as a starter for new ODF developers, explaining for instance:
* a document being a directory with a MIME type within our ZIP
* the high-level structure of a text document being a sequence of paragraphs and tables (the latter an anomaly of being two-dimensional arrays in the document tree)
* Heading & lists can be viewed more simply as paragraphs with additional information
The whole feature aspect becomes also interesting when our new charter reads: "Office apps with different feature sets should be interoperable."
Wouldn't it be helpful to define these features? Even more, shouldn't an ODF application being able to pick features like cherries from the specification?
Shouldn't the whole specification be rather feature-centric in the future?
For instance, ODF features - like a table - might be defined as a chapter referencing dependent features, which will be reused. We might want to start defining at first features being used in text documents to split the complexity.
Michael mildly coined the idea as 'tendency of something destructive' and gave a valid warning! We certainly don't want to disturb our TC's daily work by spending too much time refactoring our specification or even run into inconsistency by manually maintaining two different versions of the design of our specification (duplicated data problem).
Instead, we could avoid this situation by aiming to generate the new structure of the specification (and likely as well new parts in our former specification design).
This would allow us a smooth transition.
A trick was mentioned before to generate a human-readable spec from all data, which is interesting to software implementations, instead of extracting this relevant information for ODF applications.
Only if we are able to generate the specification and allow dependent software to access the relevant information automatically, we are able to close the existing gap between software standardization (blueprinting) and fast iterative software releases (of agile development).
Kind regards,
Svante