[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Generic CT proposal - an implementer's look at it
Hi, prompted by the recent activity around the two alternative change tracking proposals, let me add the perspective of another implementer (LibreOffice) to this discussion. First off, I'd like to say that I find the generic proposal for conditional modifications of xml elegant and concise - but I'm afraid I cannot see a way to implement it, in a way that ensures sufficient interoperability between different producers and consumers. Here's the crux: because the proposal relies solely on generic modifications of the xml info set (both structurally, by changing the tree, and by modifying attributes), and all those operations are considered valid (section 3, items 6 and 7 of the generic-ct-proposal), the set of semantically distinct editing operations *is unbounded*. Which is a fundamental problem, for all applications that need to map the change tracking markup into their internal, optimized-for-editing document models - because what you have here, is a limited set of editing operations, that are closely related to concrete user actions ("insert" an object, "delete" an object, "merge" two objects - with a very application-specific meaning, that may not map 1:1 to the xml representation). Because of its genericity and expressive power, the generic ct approach would be a very leaky abstraction over a producer's internal representation - i.e. it would be very likely that different applications produce different ct markup, for an otherwise semantically identical user action - then in turn putting the onus of interpreting that action correctly on the consuming application. Cheers, -- Thorsten
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]