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] Generic CT proposal - an implementer's look atit


On Sun, 2011-04-03 at 00:00 +0200, Thorsten Behrens wrote:

> Hm. With the generic proposal, apps would never be provably able to
> handle all cases (unless processing is very close, or on, the xml
> info set). Whereas for a bounded set of ops, one would at least be
> able to state "we don't support X, Y, Z yet" - and eventually get
> there. 

Perhaps having one or more "levels of compliance" for the generic
proposal. Each level listing explicitly what of the generic change
tracking must be supported for use cases.

Something like "light" being
* text insert, update, delete.
* para split/merge
* text style tracking

And "Basic" being light plus
* delta:merge for table and figures, including cases of whole table
deletion.
* ac:change recording of ODF attributes (insert-list-here).

And "Document Computing" level including a bunch more explicit use cases
which would be desired for serious document modifications. But I'm
likely not the one to define these classes.

This would give a concrete, bounded target, an app would need to support
generic change tracking (GCT) on certain attributes and elements which
are explicitly listed in a compliance level. This gives an explicit
bound on what is needed and apps of a compliance level should
interoperate as they know what each should support.

Of course, if an app uses GCT for more attributes or document
modifications then that's great too. I would imagine that other apps
would add support to match that support as time goes by.

> 
> Cheers,
> 
> -- Thorsten




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