IRC log from today's meeting - 2013-08-28

[Svante Schubert <svante.schubert@gmail.com>]

Please find the IRC log of today's meeting below. 
Our next meeting will be in about two weeks on the 11th of September:

http://www.timeanddate.com/worldclock/meetingdetails.html?year=2013&month=9&day=11&hour=13&min=30&sec=0&p1=179&p2=37&p3=136&p4=234&iv=1800
https://www.oasis-open.org/apps/org/workgroup/office-collab/event.php?event_id=33777

The teleconference login data for next call will be found in the OASIS calendar event (URL above).

Attendees: Oliver, Peter, Patrick, John, Svante.

[15:30] Svante Schubert: Hi everyone

[15:31] Oliver-Rainer Wittmann: moin moin

[15:34] Peter Rakyta- MultiRacio Ltd.: Hi there!

[15:38] Svante Schubert: Hi Peter

[15:38] Oliver-Rainer Wittmann: Further question for John: Why MS Word 2010 opens MS Word 2013 created ODF text document without any complain?

[15:40] Svante Schubert: Patrick: Summarizing his mail on the list

[15:41] Svante Schubert: https://lists.oasis-open.org/archives/office-collab/201308/msg00001.html

[15:42] Svante Schubert: A user reviewing changes on a document may accept/reject any change in arbitrary order

[15:43] Svante Schubert: The problem of multiple users is similar to this accep/reject problem, as changes are being accepted out of "document order"

[15:44] Svante Schubert: Assume we have sequence of operations

[15:47] Svante Schubert: Ordered sequence example -https://lists.oasis-open.org/archives/office-collab/201308/msg00000.html

[15:47] Svante Schubert: Imagine someone is inserting three paragraphs with a, b, c in a sequence
insert a @1
insert b @2
insert c @3
but it would be the same document, if the user starts with c and puts b before and finally a at the very beginning
insert c @1
insert b @1
insert a @1

[15:48] Svante Schubert: ^^ in the end it is the same document

[15:48] Patrick: Do we need a sequence of operations to preserve positions?

[15:49] Patrick: In other words, are positions held by variables that change as the document changes

[15:49] Svante Schubert: Reading the sequence here from top to down. The position 1 is valid at the point of time the operation was triggered

[15:51] Svante Schubert: In the first sequence the user would write down a,b,c in the second example

[15:52] Svante Schubert: the user is starting with c going up with cursor and adding before c the b and so on..

[15:52] Svante Schubert: In the end there is the same document, showing a b c

[15:53] Svante Schubert: If we have the same document the stacks of ops are the same

[15:53] Svante Schubert: how do we transform one operation sequence into the other

[15:53] Svante Schubert: The first stack, I would call "normalized" operations!

[15:53] Svante Schubert: They are in document order and without redundancy

[15:54] Oliver-Rainer Wittmann: What makes the first stack "normalized"?

[15:54] Svante Schubert: insert a @1
insert b @2
insert c @3
insert c @3

[15:54] Svante Schubert: delete c @3

[15:55] Svante Schubert: "normalized" as compressed and ordered information

[15:55] Svante Schubert: Patrick: We do not need a "normalization"

[15:55] Oliver-Rainer Wittmann: "in document order" means "all position values are increasing or staying the same, but not decreasing"?

[15:56] Svante Schubert: yes

[15:56] Svante Schubert: So, you may find a rule, that when switching two operations in a sequence, and they one is before or at the same position, the position will be adapted

[15:59] Patrick: By position "will be adapted" you mean if accepted, the variables in the change stack will be updated for the insertion or deletion?

[16:00] Svante Schubert: If the user would like to reject a paragraph from the document and the document sequence was the first:

[16:00] Svante Schubert: insert a @1
insert b @2
insert c @3

[16:01] Svante Schubert: Only the last one can be removed without making the operation sequence invalid, as a gap appears

[16:01] Svante Schubert: reject paragraph insertion == removal of paragraph

[16:02] Svante Schubert: We want to take one operation out, but we do not want influence other positions

[16:03] Svante Schubert: Patrick: Why is this a requirement?

[16:03] Svante Schubert: In the end you want to remove one operation

[16:03] Svante Schubert: and you want to keep the operation sequence valid

[16:04] Svante Schubert: You might as well say, how do you know which other operations you need to adapt the positions

[16:05] Svante Schubert: In other words, I want to order the sequence in a way, that I can remove the 'last' op without any problems

[16:05] Svante Schubert: all other positions are adapted

[16:05] Patrick: You should not need to adapt other positions in order to perform an operation

[16:05] Svante Schubert: And from the above seqences it is always the last one (the bottom operation)

[16:05] Patrick: Each operation stands on its own

[16:06] Oliver-Rainer Wittmann: I think what Svante to say is, when you want to reject you have to move the operation in the stack to the bottom - making it look like that it is the 'last' one that had been performed

[16:06] Svante Schubert: yes, thank you, Oliver!

[16:06] Patrick: Oliver, so I would have to re-order the stack for every change?

[16:06] Oliver-Rainer Wittmann: s/Svante to/Svante want to

[16:07] Svante Schubert: yes, if you want to take out one operation the bottom approach is like a "brutal force" algorithm

[16:07] Svante Schubert: Like bubble sort for search algorithms

[16:07] Oliver-Rainer Wittmann: similar for accepting an tracked change - making it somehow 'untracked'

[16:07] Svante Schubert: It is not the clever way, but for human the most insightful

[16:07] Oliver-Rainer Wittmann: in this case you have to move it to the top. Right?

[16:08] Patrick: If we are collaborating and you re-order the stack, what do you have to send me for me to apply the re-ordered stack?

[16:09] Svante Schubert: @Oliver: aye, you mean accept

[16:09] Svante Schubert: yes

[16:09] Patrick: Oliver - If accept, must move to the top of the stack.

[16:12] Svante Schubert: Oliver: Would like to be able to clean-up a document from change-tracking, which should be within the specification. To be certain not to send unwillingly sensitve data in a document unseen.

[16:14] Patrick: Oliver - Should purging of changes on acceptance/rejection be a user's option?

[16:14] Svante Schubert: If an operation is being accepted

[16:15] Oliver-Rainer Wittmann: to Patrick's question: yes

[16:15] Svante Schubert: it does not have to be in the opeeration undo queue any longer

[16:15] Svante Schubert: it would be removed from the queue, at the top (IMHO atm)

[16:15] Oliver-Rainer Wittmann: that is functionality currently working in OpenOffice Writer

[16:15] Svante Schubert: no prototype on queue with acception/rejection yet, so I am not 100% sure

[16:16] Oliver-Rainer Wittmann: The "funny" thing here will to identify operations which can not be accepted.

[16:16] Oliver-Rainer Wittmann: s/will/will be

[16:17] Patrick: Oliver - "..which can not be accepted" do you mean a conflict between insertion and deletion of the same paragraph?

[16:17] Svante Schubert: If an ODF operation is not aware of change-tracking the to be rejected/accepted changes are viewn and in the ODF XML

[16:18] Svante Schubert: The queue of changes just gives the ODF CT aware application the ability to localize and undo the change

[16:18] Svante Schubert: It stores the information to UNDO the user action

[16:19] Svante Schubert: Like if the user has deleted an "A", it would be the inverse operation of insertion of an "A"

[16:22] Patrick: A document has no fixed order when it resides in an in-memory model. It has a fixed "document order" only when serialized out to XML syntax. Therefore we can make changes (operations) in any arbitrary order, so long as we track their insertion/deletion against the in-memory model.

[16:25] Svante Schubert: Still we need to keep of the operation order as the position used in an operation is depending on its place/order

[16:32] John Haug: (Oliver-Rainer: I saw your question late and didn't want to interrupt.: Because Office 2013 does not write out the version attribute.  We made a decision to write non-conformant ODF 1.2 documents by omitting the attribute in order to maintain interoperability with older applications written to be strictly conform to 1.1.  The way the attribute was added in 1.2 made it incompatible by definition with 1.1 - 1.1 does not allow unknown attributes there and 1.2 requires it.)

[16:32] Peter Rakyta- MultiRacio Ltd.: bye

[16:33] Oliver-Rainer Wittmann: thx John.

[16:33] Oliver-Rainer Wittmann: bye

[16:33] Svante Schubert: bye