[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Comments on OpenDocument-v1.3-wd01-part5-changetracking.odt
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,Fixed this. I removed the property at "Replace". 2.3 Positioning ComponentsYes. Two additional information:
3.7 Images, Shapes, ChartsYou 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:
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]