Dear SC,
It seems we made a big step forward, today. Patrick and I were able to sort out a big junk of the problem.
We agreed that we have to define logical feature from the ODF XML in a way that they are always consistently implemented by ODF applications. Consistent in a way, that either the feature is fully or not implemented, nothing in-between. Patrick's example of draw:image/text:p showed that the element tag itself is not sufficient to define a consistent feature.
Only if collaborating ODF applications can rely that others are referring to the identical ODF feature set within the ODF XML, collaboration will be successful. Nevertheless, it is possible that collaborating ODF application implement more or less features, like Vi/Emacs collaborating with LibreOffice/Microsoft Office, as long both at least implement some of the same ODF features.
We agreed that the description of ODF XML might be best made by XPath. Although the application does not have to understand XPath during run-time, it should be able to resolve the logical entities at run-time similar as if the object model would be saved and XPath would be applied.
As rule of thumb, regarding paragraph it is likely that every new definition of a text:p element within the ODF XML grammar (RelaxNG) is a new feature set, which has to be addressed differently. By this draw:image/text:p and office:body/text:p would be addressed different via changes.
Next we might want to investigate the different occurrences of <text:p> in the ODF RelaxNG and how they group to feature sets.
Our next meeting will be on the 14th of December:
The teleconference login data for next call will be found in the OASIS calendar event:
Please find the IRC log of today's meeting below:
Attendees: Patrick, Svante
[16:33] anonymous morphed into Patrick
[16:37] Svante Schubert: Offtopic: There was a conference last week in Berlin, called "IMPROVING LONG-TERM DIGITAL PRESERVATION"
[16:37] Svante Schubert: http://experienceworkshop.preforma-project.eu/programme/
[16:37] Svante Schubert: EU project on validating file formats, not yet including ODF/OOXML
[16:37] Svante Schubert: Focusing on PDF, TIFF, etc.
[16:38] Svante Schubert: Especially the PDF validation approach was interesting - http://experienceworkshop.preforma-project.eu/wp- content/uploads/2016/11/ PREFORMA-Experience-workshop- veraPDF-presentation.pdf
[16:38] Svante Schubert: Because has no grammar as ODF has
[16:38] Svante Schubert: They defined their Syntax first via a DSL and based rules upon in XML to validate them
[16:39] Svante Schubert: But it did not work and I gave response and coming back to it later on the ODF TC list
[16:40] Svante Schubert: We started discussing - https://lists.oasis-open.org/archives/office-collab/201611/ msg00007.html
[16:50] Svante Schubert: Patrick: We should have taken out draw:image/textfrom the specification
[16:51] Svante Schubert: http://docs.oasis-open.org/office/v1.2/os/OpenDocument- v1.2-os-part1.html#element- draw_image
[16:51] Svante Schubert: In general, text:p and text:list as latter is just a text:p with a list property
[16:51] Svante Schubert: Patrick: As we never defined how to handle the paragraph/list. We failed to change the schema.
[16:58] Svante Schubert: Patrick: As basic, people who want to collaborate have to start with the same document (base) and the goal is that they all finish with the same document
[16:59] Patrick: add to third paragraph - applications must be counting the same features to arrive at the same count -
[17:00] Patrick: what if they count different feature sets?
[17:01] Patrick: Q: why do we have to say <text:p> without path context? Doesn't the path distinguish the occurrences of <text:p>?
[17:03] Svante Schubert: Yes, the path is distinguish the <text:p>, but before you gave the example someone could think that the draw:image/text:p is counted similar as all the others.
[17:04] Svante Schubert: The rule of thumb was, that no nested paragraph is a logical paragraph representing the paragraph feature
[17:04] Patrick: change tracking cannot account human error
[17:04] Svante Schubert: +1 :)
[17:04] Svante Schubert: What I am aiming for is to "mark" similar logical feature in ODF XML grammar.
[17:07] Svante Schubert: The use case is that someone is creating a new application and would only like to implement the basic feature of text and paragraphs as close as other ODF applications does, then draw:image/text:p should not be considered.
[17:07] Svante Schubert: Even paragraphs from header/footer are out-of-scope.
[17:08] Svante Schubert: Not only are they artifacts of how we render header/footer, it is also more complex to get the page style and footer/header content from the styles.xml
[17:16] Patrick: same elements can cover different logical features
[17:17] Patrick: in other words, the text:p in office:text and text:p in footer, etc
[17:17] Patrick: OK, different "logical" elements but only with a shallow understanding of XML
[17:18] Patrick: distinguish paragraph in running content from paragraph in footer, but they are both "paragraphs" in some sense of the word
[17:18] Svante Schubert: My problem is that I want to map the ODF document to a sequence of changes. I need to specify how to write a parser that maps the ODF XML to changes. Applications may implement different features. We need to define this feature sets. text:p does NOT represent a feature set of paragraphs, as it is not consistently implemented by applications (see draw:image/text:p).
[17:19] Patrick: we track changes 1st level is office:text/text:p - text:p in any other context, doesn't count
[17:20] Svante Schubert: But are we absolute sure, that there is no other text:p that belongs to this group of text:p ;)
[17:20] Svante Schubert: Hint: What about a text:p within a cell?
[17:20] Svante Schubert: Why not showing the text of a table?
[17:21] Svante Schubert: I am always considering my Emacs/Vi versus MSO/LO example
[17:22] Svante Schubert: Does the VI/Emacs might be happy to be able to edit this paragraph content as base text? Or might some other applications got counting problems as they ignore tables in general?
[17:23] Patrick: <table:table-row><table:table-cell><text:p>
[17:24] Svante Schubert: yes
[17:24] Svante Schubert: You are right, we would not make something wrong if we split the feature groups. I will think it over how to serialize/distinguish it in a change..
[17:26] Patrick: counting is always in context
[17:27] Svante Schubert: For every text:p defined in the ODF relaxNG, we will have a different logical group
[17:27] Patrick: What if an implementation doesn't implement <text:p> in this _expression_ - <table:table-row><table:table-cell><text:p> - that means that the implementation that doesn't implement it, can't track those changes
[17:29] Svante Schubert: And two applications with different feature can collaborate, as long every feature set is fully implemented and not for instance SOME of the office:body/text:p are counted.
[17:31] Svante Schubert: In such a broken case, the command to change the 3rd paragraph's background color to red would refer to other paragraphs in the two ODF applications.
[17:31] Patrick: if application counts other than by XPath, then counting can be broken quite easily. if always count by XPath, then it can't.
[17:31] Svante Schubert: At least the counting of the application have to be equivalent to the XPATH counting.
[17:32] Patrick: the equivalent results to XPath
[17:32] Svante Schubert: sure
[17:34] Svante Schubert: bye