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


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. But I think this is achievable with both your proposals - if
>> there's a well-defined bijective mapping between components and xml,
>> any import and export code can apply this mapping on the fly.
>>
>> Cheers,
>>
>



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