[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
Hi,
> Operations are being added upon a stack/queue. Each operation is working
in
> relation to the document state at their time. Every operation is simply
added
> upon the stack, there is a basic time/stack depth relation.
I am not sure, if it needed that operations need to be on a stack/queue for
an intrinsic change tracking.
My view is:
In general two changes are independent unless the changes are touching the
same content. Even if they are touching the same content they can be
independent - e.g., formatting a text as bold and afterwards as underlined.
I admit that certain changes are depending on each other, but this is not
the general case from my point of view.
I think it is an important feature of CT in an application that certain
changes can be rejected/accepted independently. This feature is not really
supported by bringing the changes into a strict order.
Another important feature for me is the following:
When I am editing a text document I want in general that the changes are
tracked. After some editing, I would like to run my spelling tool to
correct automatically my typos. The changes made by the spelling tool
should not be tracked. Now, it depends how the internal data structures in
my application in combination with my spelling tool are working to together
in order to keep the already created CT.
May be the document workflow consists of independent tools working on the
ODF document.
In order to have such a document workflow working each tools needs to be
deeply CT aware. I am currently not sure, if an extension to MCT is needed
to better support such document workflows.
Mit freundlichen Grüßen / Best regards
Oliver-Rainer Wittmann
--
Advisory Software Engineer
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Beim Strohhause 17
20097 Hamburg
Phone: +49-40-6389-1415
E-Mail: orwitt@de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzende des
Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294
From: Svante Schubert <svante.schubert@gmail.com>
To: office-collab@lists.oasis-open.org
Date: 25.09.2012 12:39
Subject: Re: [office-collab] How do we count? - September 26, 2012
Sent by: <office-collab@lists.oasis-open.org>
I realized I could have added two more..
On 25.09.2012 12:02, Svante Schubert wrote:
...
Let me try to summarize what we already discussed on this topic:
Axiom:
Each Operation is being defined/specified in our ODF
specification as parametrized XML change. Therefore every
operation is label representing an interoperable traceable,
reproducible document change.
Provisional First Prototype Model:
Operations are being added upon a stack/queue. Each operation
is working in relation to the document state at their time.
Every operation is simply added upon the stack, there is a
basic time/stack depth relation.
Operations are able to be moved within this stack. In other
words, it is possible to switch two adjacent operations in
their order.
During a switch position parameters of one of the two
operations might need adaption, whenever one of it is is the
creation/deletion of a preceding sibling or ancestor (being the
other), see presentation slide 17.
Note: There are logical boundaries, like the deletion, or
manipulation of a component can not be moved in front of the
creation of the very same component.
Operations are equal to functions and function composition is
applicable, like instead of having two operations adding a
single character, we might have a a single operation adding
these two. Allowing the condensation of the applied operations.
Maintaining the same overall document change or change info
set.
Should a Operation being removed from the stack, the simplest
view (algorithm) is move the operation to be removed at the
very top of the stack, so it is similar as the operation had
been the last Operation being added to the document, working on
the very last state with - most important - no side-effects to
other operations (those had been resolved during movement
through the stack).
Operations are aligned to the metadata such as time and user (see
https://lists.oasis-open.org/archives/office-collab/201206/msg00007.html
)
Operations from the same user on the same component can/should be
compressed and held grouped together
Groups on Operations on components as described above, can/should be
ordered similar to the component document order to archive an
ordering towards normalization of operations. (The highest
normalization of operation might be to keep only most compressed
create operations the stack ordered as the document ordered, similar
as being triggered when loading a document (see SAX approach
https://lists.oasis-open.org/archives/office-collab/201209/msg00048.html
).
Several of those points are only for understanding purpose and will
certainly not make it into the specification. Those constructs are only as
aid for implementors and will happen behind the scenes.
Talk to you tomorrow on the call!
Best regards,
Svante
Are there questions to the draft statements above?
Best regards,
Svante
--
--
-----------------------------------------------------------------
Robin La Fontaine, Director, DeltaXML Ltd "Experts in
information change"
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
---------------------------------------------------------------------
To unsubscribe, e-mail:
office-collab-unsubscribe@lists.oasis-open.org For additional
commands, e-mail: office-collab-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]