|
On 25.09.2012 11:28, Robin LaFontaine
wrote:
On 24/09/2012 14:40, Thorsten Behrens wrote:
Andreas J. Guelzow wrote:
On Fri, 2012-09-21 at 15:43 -0600, John Haug wrote:
So each time an arbitrary change is rejected or the document content
is altered (change-tracked or not), the numerical references of
some/all the change tracking markup may be invalidated and must be
recalculated by the application, right?
I can't imagine that any application would likely work directly on the
xml representation.
Right. We're talking about import/export filters here - for those, I
would think absolute or relative references are equivalent in
computational complexity (aka big-O). As a first cut,
implementations could simply maintain integer counters for the
components of interest, updated as the file gets imported /
exported.
Cheers,
John is I think correct in identifying a complexity here.
It is not to do with the use of XML representation, it is to do
with the fact that a deleted paragraph (say) is part of the
counting before it is deleted but is not part of the counting
after it has been deleted.
That is fairly straightforward to handle in collaboration when
the edits are expected to be executed in order, but not so easy
for change tracking where anything can be 'rejected'.
On input the application needs to work out the numerical
references not only for the actual document as read in but all
its previous states as changes were made. I think this will
become clearer when there are some more complex worked examples
- it is almost impossible to work out without working code.
For example, in a sequence of 10 edits (where edit 1 is the
first and edit 10 is the last), if edit 3 deletes a paragraph it
is impossible to know where the paragraph was (i.e. where to put
it back if that edit is rejected) without going back through
(e.g. rejecting in some virtual environment) edits 10, 9, 8, 7,
6, 5, and 4.
Note: There seems to be a difference between collaboration
(which references the components in the document as it was
before a change) rather than CT (which references components in
the document after the change). I am not sure which way MCT
works, I thought it was CT according to the earlier
presentations, but the Select Committee had all their examples
as collaboration. It would be good to have that clarified.
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).
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
|