Re: [office-collab] Convergence of proposals

[Robin LaFontaine <robin.lafontaine@deltaxml.com>]

Thanks for these useful notes, Frank. Comments below.

On 20/04/2011 14:21, Frank Meies wrote:

4DAEDDE9.5060200@oracle.com" type="cite"> Hi all,

most of these issues have already been discussed by various members in different postings/calls but please allow me to sum them up as they are quite important from my point of view:

1) The issue of whether the scope of the elements/attribute of the GCT Proposal has to be restricted has been raised quite a few times and I think that there's kind of agreement on this, right?

Yes, I believe so: some restriction is needed, possibly in the form of conformance classes or simply in the RelaxNG grammar. These restrictions would ensure that only operations known by editing applications would be allowed. It has been suggested that an unrestricted mode also has use cases - I agree with this - and the key here would be to ensure that it is simple to convert from unrestricted to restricted. This should be the case: ignoring/deleting change history for a particular element should be a simple operation.

4DAEDDE9.5060200@oracle.com" type="cite">
2) If you restrict the GCT Proposal to some common user actions, there won't be that much of a difference between the GCT and the ECT Proposal from the application feature point of view.

From the application feature point of view, I think you are right, in the sense that both can record such changes. But we want to widen the scope of CT so we need to consider how each proposal moves on to do this - see also your comment 6 below.

4DAEDDE9.5060200@oracle.com" type="cite">
3) The specification of the CT in the ODF spec has to be accurate and non-ambiguous.

Agree - this is one of the big problems with the current CT, e.g. it wraps deletions in a way that is not well defined, and this is a reason why Microsoft could not implement it: as Doug said in his blog at the time, "Each implementer must decide how to synthesize markup to make each piece of deleted content into well-formed XML, and then later – when it comes time to accept or reject the change – each implementer must make decisions about how to distinguish between the synthesized packaging and the deleted content itself. Unfortunately, the ODF specification doesn’t provide much guidance on this complex topic." (http://blogs.msdn.com/b/dmahugh/archive/2009/05/13/tracked-changes.aspx)

4DAEDDE9.5060200@oracle.com" type="cite">
4) We have to make sure that the XML won't get bloated, this applies especially to spreadsheet document where in theory all changed values and formulas could be tracked.

Yes, though short and non-ambiguous is not always easy to achieve! Apart from spreadsheets, there has been some concern on this front re ECT 'buckets' and the size of these.

4DAEDDE9.5060200@oracle.com" type="cite">
5) On the one hand we have to make sure that the complexity of the XML is kept within a reasonable range (see the list item merge example in GCT 6.15). So we should consider using insert/delete (see ECT Supplement 1) to avoid complexity. On the other hand the ac:change attribute in the GCT Proposal provides a handy means to keep the xml code dense (given that 1. is considered).

Yes. Insert/delete always looks simpler in XML (it is Level 1 in GCT) but for a user means that content is deleted and inserted where this has not been done. Simple/intuitive to a user is not always simple in XML. If content has not been deleted and inserted, why should the CT show a delete/insert?

4DAEDDE9.5060200@oracle.com" type="cite">
6) We have to make sure that interoperability with the Microsoft Office Products can be achieved (at least on the feature level). This holds true for the GCT Proposal, most likely this also holds for the ECT Proposal.

Yes. But as the features in Word and ODF applications are constantly changing, this is a moving target so CT needs to have flexibility to respond to changing needs.

4DAEDDE9.5060200@oracle.com" type="cite">
Regards,

Frank

--

Frank Meies | Software Developer
Phone: +49 49 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.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven

Oracle is committed to developing practices and products that help protect the environment

-- 
-- -----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd  "Change control for XML"
T: +44 1684 592 144  E: robin.lafontaine@deltaxml.com      
http://www.deltaxml.com      
Registered in England 02528681 Reg. Office: Monsell House, WR8 0QN, UK