ODF Convention over Configuration

[Svante Schubert <svante.schubert@gmail.com>]

ODF allows a lot of various (style) settings. For example each application has their default styles similar to browsers.
Does someone remember if there ever were discussions about approximation on any ODF list?

This configuration diversity problem becomes apparent when two different ODF applications start a real-time collaboration (or change-tracking).
For instance, if one client says it starts (or inserts) a new empty text document, does the other client has all sufficient information?

Unfortunately not. With heterogeneous clients there is no agreement of what an empty document does look like. It is likely the complete "empty" document is being wired otherwise the result might differ in the end.
When the environment is homogeneous there is of course little problem. For instance in the ODF Toolkit, I have added an empty ODT document within the JAR, which is being loaded whenever a new Text document is created:
TextDocument odt = TextDocument.newTextDocument(); // see cookbook


Similar problem occurs with styles. For instance Libre|OpenOffice users are able to choose from a predefined of preset styles as "Default", "Heading 1", "Heading 2", .., "List", "Numbering", "Table Heading", etc.
Again, fine for an homogeneous environment. All those styles have been added to my empty text document within the ODF Toolkit JAR as template.

But if each of these styles should be used during real-time collaboration with various clients, all information have first to be agreed. It might even happen with heterogeneous clients (two users with two different clients working on the same document), that one user using a different style for "heading 1" than another user working in a different part of the document. Producing an undesired inconsistent look & feel of the document.

To prevent the overhead traffic and the stylish chaos, it makes sense to agree on a naming for styles to indicate of being the default style of the component (e.g. "Table Heading"), default style properties for all these components as a fall-back - when no properties were being set and the ability to exchange the complete set of styles against a custom style palette. Like a style palette representing a certain application.
If those custom style palettes could be gathered and downloaded from a centralized place from the Internet, like OASIS or Maven repository, users would have a much greater flexibility.

The request to discuss the above is triggered by two problems:

1. When I generate ODF components on the server - like a table - what style should be given, if the server should work for various clients / ODF applications.
2. If we use this software design paradigm convention over configuration, we could save a lot of network traffic and storage for change-tracking, if we could agree on the mechanism of style palettes.
   

There is no immediate action required. I just wanted to know if some of you might have stumbled over the same problem or worth do discuss and might think it is a good direction to follow.

PS: Sorry, for my absence on todays call. I intended to bring this up, today, but did not return in time to make the call.

Best regards,
Svante