OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[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,

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:
  1. 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.
  2. There are some concepts in IT to enable distributed work, for instance 
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:
  1. Is the change marked as blob in ODF applications, like the formula has changed?
  2. 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]