Please find the IRC log of today's meeting below.
Our next meeting will be in two weeks on the 30th of January.
Attendees: John, Patrick, Svante, Thorsten, Oliver
[15:31] thorstenB: hi there!
[15:32] Oliver-Rainer Wittmann: hello
[15:32] Svante Schubert: Hello everyone
[15:34] Oliver-Rainer Wittmann: attendees: John, Patrick, Svante, Thorsten, Oliver
[15:35] Svante Schubert: Oliver explains the outcome of his action item. The specification of the insertion of paragraph.
[15:41] Svante Schubert: "The position of the ODF component is specified by change tracking attributes ct:area, ct:start and ct:end."
[15:41] Svante Schubert: Oliver: Area might be the main content or header, footer.
[15:47] Oliver-Rainer Wittmann: ODF applications may support different sets of "ODF components". Thus, do we need something for the ODF producer of the ODF to express its supported sets of "ODF components" in order to allow ODF consumers to "count" as the ODF producer?
[16:00] Svante Schubert: That would be one possibility. The other is to standarize a fixed set and allow no difference to it.
[16:02] Oliver-Rainer Wittmann: BTW, the list of siblings of <text > in Svante's reply today is not complete.
[16:03] Svante Schubert: aye, right there are elements before/after the text-content I was refering
[16:04] Svante Schubert: An extension mechanism would help to enable an interoperability to future ODF applications as well. Eg. when ODF 1.4 has a larger feature set
[16:07] Svante Schubert: The problem that we would solve first, is the ability to transform operations based on one component set to operations based on another. That should be too difficult if you can acess the original ODF XML.
[16:08] Svante Schubert: I guess the best solution is to keep it simple first and agree on a XML element set, that is likely to become an ODF component. Especially all siblings of prio 1 components.
[16:10] Svante Schubert: Or we even count only those elements, which components we are supporting in ODF 1.3 change-tracking.
[16:13] Svante Schubert: Oliver: He desires the root elements of elements the ODF application is supporting. At least the siblings to solve the 'insert in between' feature!
[16:14] Svante Schubert: Answer to my question: He did not specify the root element for a paragraph 
[16:15] Svante Schubert: Oliver: We need some tooling to review our ODF schema, as searching in the RelaxNG text file is quite hard.
[16:19] Svante Schubert: It is not described how a paragraph is represented in XML
[16:26] Svante Schubert: Search for text: p in the wiki, it's only in the wiki example
[16:27] Svante Schubert: Its fine. You made a reference - [A] see ODF 1.2, 5.1.1 for the definition of "paragraph element".
[16:27] Svante Schubert: We agreed, we are defining the operations, not the user actions resulting in inverse operations. So the operations can be reused for CT and RTC.
[16:30] Svante Schubert: Oliver: Suggest to discuss if we need namespace (on attributes) or not. The path needs further definition. We need to define the basic/common stuff, that is being reused by other components.
[16:30] Svante Schubert: Oliver will fix this till the week-end, but other should jump in.
|