>
Yes, I believe so: some restriction is needed, possibly in the form of conformance classes or simply in the RelaxNG grammar.
And I’ll repeat from the call my concern that this may be insufficient. Restricting the tracking of general types of changes to certain elements is helpful,
but it still allows, for example, any change of that general class to be tracked on the element. So, restrictions at levels such as schema would allow tracking of changes to any attributes on a set of elements, not just ones that represent intentional changes
the user has made to the conceptual document objects represented by those elements.
What do the other experts here think – am I misunderstanding or is this a valid consideration?
>
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?
Again, let us recall from the April 12 call that specialization of the names of the change mark elements and/or elements within the text:changed-regions was
highly recommended to make it explicit to applications what user actions resulted in the change tracking markup. Indeed, I believe this is the only context in which such specialization to support clarity for interoperability has been recommended. The value
I see with this is that it combines the architectural simplicity of the insert/delete pattern with the explicitness of specialized element names, which I think supports clearer interop among implementations.
Again, is this invalid rationale?
>
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.
Actually, this is an interesting question. Do we have a sense of how much the scope of change tracking support in common applications is evolving? My sense
is that the set of document-centric user actions where change tracking is valuable is fairly well-defined and stable. Of course, this question is more qualitative than quantitative, so I’m curious what others’ perspectives are.
John
From: Robin LaFontaine [mailto:robin.lafontaine@deltaxml.com]
Sent: Thursday, April 21, 2011 3:12 AM
To: office-collab@lists.oasis-open.org
Subject: Re: [office-collab] Convergence of proposals
Thanks for these useful notes, Frank. Comments below.
On 20/04/2011 14:21, Frank Meies wrote:
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.
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.
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)
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.
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?
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.
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