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,
      

      

      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