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] How do we count? - September 26, 2012


On Wednesday 19 September 2012 14:08:49 Svante Schubert wrote:
> Patrick,
> 
> the XML model is the shock frozen document state.
> Our desire is to track and save the run-time changes.
> In addition we only want to save/track only the mandatory parts, to be
> efficient in loading and saving.
> The MCT is following is convention over configuration paradigm. To
> archive efficiency every change-event/operation call is similar to a
> label a reference to a reoccurring XML change-pattern once declared in
> our specification together with arguments making the change unique, e.g.
> insert row at the third position.
> Finally, to be easy understandable, avoid additional boilerplate and do
> not require an ODF XML representation by the ODF application during
> run-time, there will be an abstraction from the ODF XML design to
> semantics groupings we call components with properties. Our goal is to
> define operations to manipulate these and store these in the end in the
> file format.
> 
> Yes?
> 
> Hope you having a great day!
> Svante
> 
> On 19.09.2012 02:26, Patrick Durusau wrote:
> > Thorsten,
> > 
> > You are of course correct, either proposal (mine or Svante's) would work.
> > 
> > My point is that we already specified an XML model.
> > 
> > If we express change tracking against that model, we need not
> > explicitly define another one.
> > 
> > Yes?
> > 
> > Hope you are having a great week!
> > 
> > Patrick
> > 
> > On 09/14/2012 05:07 AM, Thorsten Behrens wrote:
> >> Patrick Durusau wrote:
> >>> What is required is that when I serialize the in memory
> >>> representation (my meaning of data model), is that it meet all the
> >>> requirements of the ODF format.
> >>> 
> >>> That is we specify a serialization of changes against that common
> >>> serialization so that when we exchange that representation,
> >>> applications reach a common state of the document with regard to
> >>> changes. What data model the applications are following isn't
> >>> relevant at that point.
> >>> 
> >>> Yes?
Yes ! :)


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