Re: [office-collab] Some remarks ...

[Tristan Mitchell <tristan.mitchell@deltaxml.com>]

Hi Frank,

On 12 Jan 2011, at 16:23, Frank Meies wrote:

> Hi,
> 
> let me add some remarks on the current proposal:
> 
> 1) Although the examples given in the proposal are quite telling, the new elements/attributes and their usage need some more prose to explain their purpose.
> 

Yes, I agree with you on this point. Is this extra explanation necessary at this stage to help with understanding the proposal or would it be sufficient to say that the extra explanation be added to the spec should this proposal make it that far?

> 2) The relationship between the current ODF elements and the new elements/attributes needs to be clarified, e.g., is it allowed to have the change tracking elements in the auto styles section? Or can 'delta:merge' be the child of a 'text:p' element?

Again, yes, I agree. As part of the proposal we did include RNG files that went a certain way towards defining these relationships. This was by no means complete and would need to be extended for integration into the main schema.

> 
> 3) I think we can improve the (human) readability of the text content by moving the deleted text out off the 'regular' content (see current ODF specification) into the tracked changes section. Additionally the attribute change information for attribute removal and modification can be moved into the tracked changes section as well to reduce some noise in the text content.

Yes, I agree with the first part of this. In fact the current spec states that all text content underneath a paragraph (which a few exceptions) is considered to be the content of that paragraph. In order to keep backwards compatibility, it will be necessary to change the proposal so that deleted text is moved away from the paragraph itself, in much the same way as the current change tracking.

However, I don't think this would be as simple with the attribute change tracking. Each change-transaction (identified by a unique id) can potentially cause changes in more than one element. If the attributes of more than one element are changed then it is difficult to refer to both sets of change from the same place. It is simpler then to describe attribute changes in the location at which they occur.

> 
> 4) I think the generated attributes 'split:XXX' can be replaced by a non-generated attribute 'delta:split' whose value would be a list of the respective split ids. The same holds for 'ac:XXX'.

The idea behind creating the split:XXX and ac:XXX attributes was to ensure that any given change-transaction only adds new change-tracking information to an element. If there was a single delta:split attribute, this would need to be updated when a new change-transaction affected the splitting of the element. Although having a new attribute for each split is more verbose, it does keep the created of a change-transaction and the subsequent processing of it simpler.


Regards,

Tristan


> 
> Best regards,
> 
> -Frank
> 
> -- 
> Frank Meies | Software Engineer
> Phone: +49 40 23646 500
> Oracle OFFICE GBU
> 
> ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg
> 
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
> 
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Rijnzathe 6, 3454PV De Meern, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven
> 
> ---------------------------------------------------------------------
> 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
> 

--
Tristan Mitchell, DeltaXML Ltd "Change control for XML"
T: +44 1684 869 035 E: tristan.mitchell@deltaxml.com http://www.deltaxml.com
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK