Hi Regina, Thank you for your valuable feed-back. Would you like to join our change-tracking subcommittee? :) No obligation, no strings attached, but for instance you may attend tomorrows call at 16:30 German time, all required details:
https://www.oasis-open.org/committees/event.php?event_id=33781 We would be honored. Based on your feed-back I did (am doing) an update on the draft, perhaps we can discuss any potential misunderstanding of your feed-back by my side on tomorrows call? Some further answers of mine below... Am 28.10.2013 23:40, schrieb Regina Henschel: Hi Svante, I have read the document and have some comments and questions: 2.2 Meta Operations The operation 'Replace' contains property is changing . And the operation 'Format' contains Adding/Removing one or more properties . It is not clear what is covered by operation 'Replace' and what by 'Format'. Fixed this. I removed the property at Replace . 2.3 Positioning Components If three people work on a document A. First person creates change B from A, second person creates change C von A. Both persons sent it to the third person, who will merge B and C into his A. Will such merging be possible? Yes. Two additional information: There are some changes, that would result in a merge conflict, like A = work on a cell and B = deletion of that table . The ability for an automated merge still does not prevent us to communicate. But the application might annotate changes with some kind of traffic light paradigm, where collisions are marked red , possible but very close change (e.g. text changes in the same paragraph or section) marked yellow and changes in different sections green changes. There are some concepts in IT to enable distributed work, for instance
http://en.wikipedia.org/wiki/Lamport_timestamps http://en.wikipedia.org/wiki/Vector_clock 3.7 Images, Shapes, Charts * I miss formula-objects. I know, there is currently no change tracking in formula-documents in ODF. But Microsoft Word has change tracking in inline formulas. You are right, they are missing. We are still at the beginning, but you are right, we should aim to cover the current state-of-the-art coverage of implemented change-tracking. @ODF Implementors Question: Is the change marked as blob in ODF applications, like the formula has changed? Is it possible to show the detailed changed A formula is pretty much a good example to have no merge at this level. Otherwise we need to normalize formulas on mathematical level ;) * I miss an outline topic 'frame'. You mean how to handle frames and text frames? Are they are currently tracked? I have fixed my wording in regard of nested paragraphs, of course they have to be allowed. * Charts and formula-objects are different from images and shapes, because they are complete documents by themselves in ODF. Perhaps it would be better to handle them in a different section? Yes, that might be. I have overtaken the sections from the ECT proposal. @ODF Implementors: Am I (or better John, who original created the document) right about the status on change-tracking:
https://www.oasis-open.org/committees/document.php?document_id=51238&wg_abbrev=office-collab Need flat formats a different handling? The same operation handling could be applied to flat xml as although all information in one XML stream, there is only one theoretical component tree the operations are work upon. Nevertheless regarding the flat XML file format, I have a very special view to. As the principal rule of thumb for ODF design: Do not add something to the ODF standard, which does not add functionality, but only makes the format more complex for implementers! XML flat format was mistakenly designed to enhance the XSLT handling for ODF. The reality is that computer language are able to handle access to ZIP without the need to unpack the ZIP explicitly. (E.g. in Java we used to implement a javax.xml.transform.URIResolver & org.xml.sax.EntityResolver to handle access to documents, see our Resolver in the ODF Toolkit used in a test case testResolverWithXSLT .) Especially when XSLT would require to parse all the embedded images, which usually not being used by XSLT itself, only wasting resources and not seldom lead into memory problems. Another example for this redundancy that only creates complexity are our numbered paragraphs in ODF (reference to ODF 1.2 spec ), which should be deprecated ASAP. Best regards, Svante Kind regards Regina --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php