[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 at it
Would something like this give us the benefits of both approaches: 1) Specify the complete DeltaXML generic proposal, but in its own separate "part" of the standard. 2) Then in the conformance clause for ODF, reference a subset of these capabilities for use in conforming ODF documents. For example, we could enumerate the specific places in ODF where the change tracking is allowed. Maybe schema annotations could be used for this. 3) In "extended ODF documents" allow the unconstrainted general use of the change tracking features. This matches how we treat extensibility in ODF 1.2. We have an unlimited extensibility mechanism (foreign elements) that is difficult for any processor to handle in a generic way. But this is only allowed in extended documents. For non-extended documents we allow only specific kinds of extensions, e.g., RDF metadata, application settings, etc. -Rob Thorsten Behrens <tbehrens@novell.com> wrote on 04/04/2011 04:50:16 PM: > > you wrote: > > I'm not sure if I got you correctly. You consider it problematic > > that there might be change transactions in the document that do not > > match basic user actions. > > > No. I consider it problematic that there's no limit to the > creativity in producing *atomic* changes - an application would be > perfectly allowed to delete ~all content of a huge document at once, > with only one delta:remove-leaving-content-*, and even more arcane > stuff - and you and me would end up trying to break that down to > something Writer understands. ;) >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]