I guess we all agree meanwhile that an office document as the shock frozen final state of the user's work is equivalent to a sequence of user changes creating this document.
There is an advantage to have a different view on the document, to split this monolithic complex block into changes. Changes are the 'currency' of collaboration. They are exchanged and used for merges to synchronize the paralleled work. In general, the usage of changes allows to exchange and merge minimal portions of the document, reducing complexity and in addition even enabling new features such as
multiple format changes on text as discussed on last TC call.
My question to you - which I have trouble with - is how do we slice in general the features we base the changes upon?
Let me give you an example. In ODF XML every text visible to a user is within a <text:p> paragraph element. This is basically a valid design decision, but to the user (esp. to me) the paragraph within the text flow (not even header / footer) is the most important paragraph or at least a logical class for itself. Other <text:p> rather belong to other logical unit instead being one for themselves. Sometimes a <text:p> is part of the title of a frame/picture or containing the text of an annotation (i.e. being just metadata on some document portion).
The problem might become more apparent when you think of an ODF application being started to be implemented from the green field. The first step is to show text and paragraphs only (paragraph as I define them). But in general, any application might decide would part of ODF it implements and should be able to bootstrap from arbitrary features they pick from the ODF XML to create their applications, e.g. tables, images, etc.
In my "text & paragraph-only"-example we might think of the VI or Emacs (or any other text) editor that reads ODF XML and shows every paragraph as a single line showing the text of the paragraph. Likely the only the user changes of creation of paragraph and text are being send to the editor.
By this it is possible that two ODF applications with total very different feature set do collaborate. For instance, a VI/Emacs might collaborate with MSOffice / LibreOffice in theory.
The only problem would be for the user of the VI/Emacs to decide to place a paragraph/text before or after an unknown logical object. But changing/add/delete of text/paragraph in a homogeneous part works fine.
My problem is to define a rule how to realize that the <text:p> have different meanings.
I fear there is no other solution than trial and error.
Of course, it would be a good decision to slice the ODF grammer (RelaxNG) into slices defining the logical blocks (using GraphDB), but it seems in the end we need to have ODF documents using these blocks to be loaded into ODF applications to check how applications are interpreting and rendering currently those variations of elements.
Any thoughts and/or comments?
Looking forward to exchange some ideas on this in our tomorrows call.
Regards,
Svante