OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-collab message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office-collab] The Essential Use Case


Yes, there is a conflict there between describing editing operations and the representation of the document in an XML format. How best can we address that conflict? I've been thinking about this in general terms and looking for successful approaches from which we could learn.

In ODF at the moment we have a definition of a static document and in effect we need to add the capability to represent many different documents - the last version and any previous versions as we roll back through changes (or accept/reject in some order). The GCT is certainly capable of representing that, but is considered too general so that determining the editing operations in the general case is too difficult.

Are there relevant successful approaches to similar problems? SGML was very general and powerful but too difficult/expensive to implement. HTML was hugely successful but was not new, rather it was based on a restricted form of SGML. XML likewise very successful and again based on a restricted form of SGML. ODF is itself a restricted form (vocabulary) of XML. So a generic solution which is constrained seems to work well for data representation. This is one reason why I believe it is a good approach to take a generic solution to change tracking (which would work for any XML) and restrict it to meet our needs.

The advantage of a restricted generic solution is that there is always room to grow. Removing or defining new constraints on top of a well-defined syntax leads to a more consistent solution than adding new bits for each new need.

The GCT provides all that is needed to represent any change to the document. It can be processed at a generic level to roll-back changes, just like ODF can be processed as generic XML for some operations. The issue of how to identify editing operations is solved by making specific restrictions where an editing operation is to be represented. In fact Level 1 has 'buckets' and Level 2 has what might be called movable partitions (separating out the text content in different ways). If only buckets are needed, use only Level 1 - but with the knowledge that there is more power available when needed.

I would argue that a generic solution with restrictions for specific use cases is a well-established and successful pattern.

Robin


On 09/06/2011 19:49, Thorsten Behrens wrote:
20110609184949.GE8761@thinkpad.thebehrens.net" type="cite">
Dennis E. Hamilton wrote:
The tricky part for us is that we are defining this at the format
level.  We have to be careful to specify something that those
skilled in the art will see how to achieve that objective in the
user-facing software that they provide, although that is not the
level of behavior we are specifying.  (I refer to this as the
document-format anti-pattern.  It is the cross we bear.)

Hi Dennis,

I guess that's the point I'm trying to make since quite a while. :)

Cheers,

-- Thorsten

-- 
-- -----------------------------------------------------------------
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]