Call Summary:
Basically, the talk's aim was to dispatch three bottom-up insights:
- Collaborative ODF applications require an interoperable way to dispatch "ODF user changes" in order to be able to do "real" collaboration, similar to GIT repositories. Existing approaches of "ping-pong email correspondence with two users" or "single-server time-threading with multiple users" always neglect the complexity of merging changes as nowadays GIT provides in contrast to former versioning systems. Only the definition of ODF user changes for interoperable collaboration of ODF applications will open the door to more advanced user collaboration scenarios of infinite users and asynchronous changes. Nowadays only the ODF documents are standardized and able to be exchanged in full for collaboration. Current Change-Tracking design does not support merges and allows disabling changes, which blocks the approach for trustworthy scenarios as for lawyers.
Slide 1: Showing single app state machines with their only ability to exchange valid ODF syntax with other ODF apps to be interoperable.
Slide 2: Showing multiple ODF apps collaborating on the same document and their need for exchanging changes to synchronize the document state. - ODF user changes are already a de-facto standard from a user perspective. All users expect the same ways to change their document across all ODF applications - add/modify/delete paragraphs, characters, images, tables, rows, cells. Still, these pre-defined ODF changes are not yet part of the ODF XML skeleton provided by our RelaxNG schema.
Slide 9: Naming the de-facto existing user change standard across ODF applications and the missing specification to use it in an interoperable way. - Our ODF XML grammar is nowadays a >18 thousand lines text file, which is time-consuming to read and understand. (Slide 4 showing an ODF Relax example)
To improve RelaxNG usage and make an extension for ODF changes easier, I have started to prototype the analysis of our ODF XML RelaxNG grammar by loading the text file into a graph database using the Apache Tinkerpop GraphDB abstraction software to be interoperable usage across various GraphDBs (Slide 5 Stating the approach and some questions to be solved).
Slide 6 shows a subgraph from our ODF schema visualized in the Gephi Viewer. It starts from the <table:table> element and shows all child XML elements and attributes including any other RelaxNG structural information from the schema such as optional/choice/sequence.
Slide 7 zooms a little in and Slide 8 shows another subgraph, which shows by example how the existing graph could be refactored for human readability by avoiding unnecessary boilerplate (see my comment in the IRC log from 16:48).
Future definition of changes might extend the overall created graph by properties. The addition of metadata to existing XML nodes like types for metadata, style, visible-text (for translation and text representation) are only a few of possible metadata to be added once and be used multiple times.
Last but not least, crucial information for source code like the fixed bindings between IDs and REFs within our ODF RelaxNG could be added over this extensible representation as a property graph.
The original reason for analysis and adding yet missing information to the ODF grammar was the attempt to improve the source code generation of the ODFDOM layer of the Apache ODF Toolkit (incubating). Generating structures once instead of writing it over and over again for the 598 XML elements and 1300 XML attributes of ODF.
On the 21th of February will be our next meeting:
The teleconference login data for next call will be found in the OASIS calendar event:
[16:35] Svante Schubert: Hello
[16:48] Svante Schubert: Slide 8 is showing a subgraph, which could be refactored for human readability. Blue are the XML elements.
a) The yellow vertix/node is the RelaxNG definition, which provides no additional information, if it simply mapps to the XML node that follows.
b) The CHOICE/EPSILON construct is equivalent to an optional. EPSILON is representing NOTHING, so a choice to nothing means optional.
If the choice holds only two edges, the two edges, the EPSILON and CHOICE can be exchanged against an optional label to the edge leading to the node, removing some of the boilerplate, making it easier to read for humans.
[17:01] Svante Schubert: Here the ODF XML RelaxNG snipplet representing slide 8.
<ref name="text-soft-page-break"/>
</optional>
<ref name="table-table-row"/>
[17:14] Svante Schubert: We should not be changing existing ODF model, only adding metadata
[17:15] Svante Schubert: Adding a view from a different perspective. What is the user adding/deleting/modifying?
[17:15] Svante Schubert: First we sent the cake around, now we specify how to slice it ;)
Where the cake are the documents.. :P