[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office-collab] An Abiword / Calligra developer's view of theChange Tracking events.
|
Ah, I see. I think it’s a bit difficult to draw parallels between the ways in which ODF and OOXML store change tracking markup since there are fundamental differences in how the core data is stored. Let me try to summarize my understanding,
looking at basic text changes as an example. OOXML WordprocessingML maintains a separation between the pure text and its properties. The paragraph element carries a bucket of paragraph properties along with the runs of text that make up the paragraph (a run is a segment of content
with a single set of properties). Each run of text carries a bucket of run properties next to the text that makes up the run. So, since everything is well-partitioned, changing the properties only affects the properties bucket. Changing content annotates
a run / creates another run, wrapped in an element that identifies it as an insertion or deletion (or move, etc.). For example, see the attached. Since ODF does not separate content from its properties as much, its storage does not allow for the model taken by OOXML. Unfortunately, I think this is why we see such difficulties in dealing with the nested markup in some types of
changes – the storage design conflates content and presentation and is not designed to handle well scenarios such as change tracking, particularly given that it involves moving removed content/markup around the file. One might claim the current ODF approach of using change markers to remove or annotate/wrap meaningfully whole chunks of markup is somewhat similar to how WML deals with paragraph and run property changes – the property bucket always
reflects the current state and the previous state is “backed up” as a whole bucket in the change element (e.g., w:rPrChange in the attached example). That is, both approaches seem to deal with chunks of markup representing whole objects rather than get terribly
granular. I modeled the extended proposal after this approach in ODF where possible. For example, it takes a similar approach for style changes – the change is handled at the level of the entire style rather than the numerous components within it. Although there are loose parallels between, say, WML run properties and ODF automatic styles, there seem to me to be fundamental architectural differences. I’m challenged to see how to apply the high-level architectural tenets of the
WML approach to ODF, though brighter minds than mine might see more opportunities. John -----Original Message----- On Tue, 2011-03-29 at 17:16 +0000, John Haug wrote: > Hi Ben – > > > > How closely does the "extended" proposal mirror what is performed by > Microsoft Word for non ODF formats? For me, it would be interesting to > see how these things play out, and how the user interface offers such > functionality in an existing implementation of the "extended" > proposal. > > Even if that implementation stores in non ODF currently. > > Please note that there is not yet a prototype of the extended > proposal. We haven’t jumped the gun to build anything into Word > without appropriate discussion and agreement in the SC; that is, > Microsoft isn’t attempting to force something we’ve built onto the ODF > standard. I apologize in advance if I misunderstood and that’s not > what you were implying, but I do want to make sure that’s clear to > everyone. Well, I was mainly interested in seeing how another tool performs change tracking. If Microsoft Word used similar constructs for docx then I could play around there and see how things work in another tool. (assuming I setup the platform etc). |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]