Regarding Patrick's comment on defaults of styles:
http://markmail.org/message/nv4m77mpfgtqv7dn
The document as ODT that is being represented can be found attached, so the JSON file as txt.
Note: Some naming and design of the JSON is likely to change
Take a look at the JSON file - http://markmail.org/download.xqy?id=nv4m77mpfgtqv7dn&number=1
If we would define what an empty document contains, especially what default style set, most of the all the font and style insertion might be exchanged by starting with the specified empty document.
There might be more than style sets so it should work without of struggle.
We might even define the mechanism to define a template and/or a style set and leave it to the implementers. Many options, now we should only keep the idea in mind.
Regards,
Svante
2016-07-13 17:43 GMT+02:00 Svante Schubert <svante.schubert@gmail.com>:
Dear SC,Our next meeting will be after summer vacations on the 24th of August: http://www.timeanddate.com/worldclock/meetingdetails.html?year=2016&month=08&day=24&hour=14&min=30&sec=0&p1=179&p2=37&p3=136&p4=234&iv=1800The teleconference login data for next call will be found in the OASIS calendar event: https://www.oasis-open.org/apps/org/workgroup/office-collab/event.php?event_id=39502Dial-in will be similar to the TC. Attendees: Jos, Peter, Patrick, Svante[16:29] Jos van den Oever: Hello Peter[16:29] Svante Schubert: Hi, I am dialing in[16:31] Peter Rakyta: Hi there[16:33] Svante Schubert: Agenda: https://lists.oasis-open.org/archives/office-collab/201607/msg00002.html[16:34] Svante Schubert: Agreed on canceling the next two calls[16:36] Svante Schubert: This Friday deadline for papers for the LibreOffice conference - https://blog.documentfoundation.org/blog/2016/04/08/libreoffice-brno-conference-call-for-paper/[16:39] Svante Schubert: As part of the work on the LibreOffice implementation there came this design iteration -> https://www.oasis-open.org/committees/download.php/58495/undo-20160712.xml[16:39] Svante Schubert: The related mail was https://lists.oasis-open.org/archives/office-collab/201607/msg00001.html[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:50] Jos van den Oever: https://en.wikipedia.org/wiki/JSON-LD[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:06] Svante Schubert: There is this list of requirements of XML serialization - https://lists.oasis-open.org/archives/office-collab/201607/msg00000.html[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