[16:29] Jos van den Oever: Hello Peter
[16:29] Svante Schubert: Hi, I am dialing in
[16:31] Peter Rakyta: Hi there
[16:34] Svante Schubert: Agreed on canceling the next two calls
[16:47] Jos van den Oever: json-ld is a linked data serialization
[16:47] Jos van den Oever: so any rdf graph can be xml/rdf or json-ld
[16:48] Jos van den Oever: if your model is rdf, you get xml and json serialzation 'for free'
[16:48] Patrick: XML comment - consider dc:creator on a container above <change> for a set of changes so it isn't repeated, same for dc:date for all changes in one session
[16:49] Patrick: XML comment: is c:style required if default styles are acceptable?
[16:58] Svante Schubert: We never defined prior in our spec, what a default style for a paragraph or heading level 3 would look like
[16:58] Svante Schubert: This would make a lot of sense for real-time collaboration as well, to start an identical empty document with a predefined style set
[17:00] Svante Schubert: Even in collaboration there would be an inital starting document with an agreed style set
[17:01] Svante Schubert: Would not make sense to work on a document having different heading styles for instance. Would look horrible![]()
[17:02] Patrick: Each document would have one master style, which has the defaults defined for that style in the standard.
[17:02] Patrick: There could be a LibreOffice style, with defined defaults, which are subject to being changed by a user
[17:03] Patrick: In ODF 1.2, we never defined the default values for styles to the point of interchange between implementations of ODF.
[17:04] Patrick: Doable but getting agreement may be an issue - Svante says there can be multiple complete style definitions.
[17:11] Svante Schubert: Peter, should sent the requirements to his team and ask if the two scenarios work
[17:20] Patrick: comment files could be separate by users and signed separately
[17:20] Patrick: change files too?
[17:21] Svante Schubert: As change files are from the interior identical to comment files only differently handled we should consider this.
[17:21] Svante Schubert: But if we do this, I would suggest to have an operation to reject/accept a prior change
[17:22] Jos van den Oever: signing change files should not be requirement, and neither should other signing
[17:22] Svante Schubert: And changes are identified by a integer starting from 1 counting up
[17:22] Svante Schubert: prior change files would be never touched again
[17:22] Jos van den Oever: but if it works with signing: great
[17:22] Patrick: Even if passing the file around, might need to have signed changes by user. That is you either accept or reject as a whole, i.e, invalidate the signature.
[17:23] Svante Schubert: In the mail on possible requirements (see URL above) it is point 11
[17:23] Svante Schubert: There is a unique ID on every change. For instance, an integer will do starting from "1". Changes can reference to prior change in other files. The Acceptance/Rejection of prior changes are new changes to be tracked - required for the signature scenario.)
[17:29] Svante Schubert: Sorry, I was dropped out
[17:29] Svante Schubert: Let's call it a day ![]()
[17:29] Svante Schubert: The time is over.
[17:29] Svante Schubert: Any questions, otherwise just ping me on Skype
[17:29] Jos van den Oever: ok
[17:32] Svante Schubert: Thanks for joining the call, see you after the long summer vacation ![]()