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: IRC log - ODF Collab SC call - 2017-02-08

Call Summary:
A short summary of FOSDEM conference last week-end, potential interesting companies that are being approached to join the SC and an inital discussion on a list of advantages of our approach that should be communicated to those companies.

On the 22th of February will be our next meeting:

The teleconference login data for next call will be found in the OASIS calendar event:

Please find the IRC log of our meeting below: 
Attendees: Patrick, Svante

[16:32] Svante Schubert: Hi, had been on FOSDEM last week-end.
[16:33] Svante Schubert: Some international open souce conference
[16:33] Svante Schubert: There had been and ODF editor devroom, which was mainlly taken by Libreoffice
[16:33] Svante Schubert: But there had been also some companies from France, who won some France sponsorship to build a 'French' GoogleDocs, just as open-source :)
[16:35] Svante Schubert: There was also some guy from XMPP some open-source instant editor, who like to standardize collaboration on XML
[16:35] Svante Schubert: Which is closely what DeltaXML once wanted to do
[16:35] Svante Schubert: He was quite surprise that no ODF application requires a DOM :)
[16:37] Svante Schubert: I also started talking to some office companies that are not involved in OASIS yet:
[16:37] Svante Schubert: Collabio.com (Great Britain/Ukraine/Russia), Hancom.com (Korea) und kingsoftstore.com/ (China)
[16:38] Patrick: https://twitter.com/chemconnector?lang=en
[16:39] Svante Schubert: ^^Patrick: He is tweeting about editors that allow people to collaborate. Each domain has its own idea, what a collaborative editor should be.
[16:41] Svante Schubert: The pitch from a high level view that I am doing at those companies:
[16:41] Svante Schubert: I want to exchange ODF changes instead solely ODF documents among ODF applications in the future
[16:56] Svante Schubert: What are the advantages of joining the SC?
[16:57] Svante Schubert: Patrick: Oppose to existing HTML editors, people could use editors to collaborate, which have varying capabilites.
[16:58] Svante Schubert: Patrick: We (the OASIS SC) could define a core of changes (e.g. for change-tracking)
[16:59] Svante Schubert: Patrick: We could provide the techniques to them to collaborate without loosing features, like the VI vs. Microsof Office collaboration example
[17:01] Svante Schubert: Patrick: Extending their market share, as their functionality is able to be shared with other applications using the same 'core set of changes'. No vendor lock-in and greater ecosystem for 3rd party software.
[17:02] Patrick: core set of changes -> core language for exchanging changes
[17:02] Svante Schubert: sure
[17:03] Svante Schubert: Aside of the above, there are new features/possibilites like in the past the document was read into the internal model and everything unknown was lost.
[17:03] Svante Schubert: In the future, only the known feature can be translated to operations and changes can be 'merged' into the existing document. Not breaking documents.
[17:08] Svante Schubert: By this you are able to start an ODF application with a very low feature set without breaking any advanced documents.
[17:08] Svante Schubert: In the past, the document was loaded and everything unknown got lost when it was overwritten from the new document version. Nowadays the change is merged into it.
[17:09] Svante Schubert: ^^Single user - single document scenario
[17:10] Patrick: if "merge" changes into a single document, what happens if the user changes their mind about a previously accepted change?
[17:11] Svante Schubert: The above works for every scenario - therefore even without change-tracking!
[17:12] Svante Schubert: I load a document "Hello World" in bold into 'ODF-old-habit Office', which does not know anything about bold.
[17:12] Svante Schubert: When loading there is no 'place' to understand bold, there is no generic DOM tree taking over all unkown information. So the bold is lost when loaded.
[17:13] Svante Schubert: Then I am adding a character to the text "Hello World2" and saving the text to the old document.
[17:13] Svante Schubert: Overwriting the bold feature.. Q.E.D.
[17:13] Svante Schubert: The bold is lost as I did not know it, because I overwrote the old document with my mapped core.
[17:13] Svante Schubert: ^^That is the general habit of the old offices in the world.
[17:14] Svante Schubert: Nowadays, offices that using changes are mapping the ODF to changes when being loaded.
[17:14] Svante Schubert: The editor is creating the document from the changes given from the ODF2Changes library
[17:15] Svante Schubert: Every new user change within the editor creates a new change, which is put in a list.
[17:15] Svante Schubert: Each change of the list can be merged into the existing document without deleting the previous unknown information.
[17:15] Svante Schubert: Voila!
[17:15] Svante Schubert: For instance OX Documents is doing it this way.
[17:17] Patrick: OK but I take exception to the use of "merged" because the change is still in the list of changes and so the application saves the original document, plus the changes, still in the list. That is changes are always added to the list and the base starting document is never changed.
[17:18] Svante Schubert: Oh, it applies the changes from the list to modify the ODF XML
[17:19] Svante Schubert: Don't forget, these changes are not being used for change-tracking.
[17:19] Svante Schubert: These changes are the interoperable data-package between applications
[17:19] Svante Schubert: In this case a server mapping the ODF to changes and sending those to changes.
[17:22] Svante Schubert: In OX there had been a server in Java doing the document to changes mapping and a browser for user front-end and editing.
[17:22] Svante Schubert: But this could be all in one application
[17:24] Svante Schubert: Another advantage of changes:
[17:24] Svante Schubert: We only dispatch the change, so we can merge multiple user changes by merging only the changes.
[17:25] Patrick: <text:p>Hello World</text:p> even though <text:p style="bold">Hello World</p> was the original. If add <text:p>Hello World2</p> then original app sees: <text:p style="bold">Hello World2</p> b/c string changes occur in the same element as the original text
[17:25] Svante Schubert: In other words, the complexity of the merging multiple user changes is independent of document size.
[17:26] Svante Schubert: So, I have one change and you have.
[17:26] Svante Schubert: I am making the 1millionth paragraph background red
[17:26] Svante Schubert: You are inserting a new second paragraph
[17:26] Svante Schubert: We can merge our changes simply without parsing both documents
[17:28] Svante Schubert: Dependent if your changes comes first, my is 1millionth + 1 paragraph being changed, otherwise if my change is coming first the position is the same :)
[17:29] Svante Schubert: But the overall story is we do no longer have to parse our documents to realize what the change is and how to put them together
[17:29] Svante Schubert: ..after coming back from off-line collaboration work over the week-end.
[17:29] Svante Schubert: Patrick: Applications can be still be stupid and do all the parsing, but it allows future applications to be smart and efficient!
[17:31] Svante Schubert: Oh, last but not least. We should do some hashing of the state based on the logical structure (based on a known feature set) oppose to hashing the amiquious XML
[17:32] Svante Schubert: This is necessary, as I really like to provide Versioning Support like in development used for source code for ODF.
[17:33] Svante Schubert: Like GIT support for ODF that goes beyond the binary diff, by using ODF changes to express the diff!
[17:33] Svante Schubert: Best thing of all, the diff is at the same time the instruction set to transform one document version to the other!
[17:34] Svante Schubert: Usually a diff is line-based on text documents
[17:34] Svante Schubert: that does not work with our ODF XML
[17:34] Svante Schubert: as it can be all in one line or in multiple and even spans can be nested or a single one.
[17:35] Svante Schubert: Working on the logical level that we are defining the changes on would solve this problem.
[17:35] Svante Schubert: So, I am looking for customer / enterprise use cases that make such techniques mandatory to have to solve those!
[17:37] Patrick: comments on laws as changes to the documents
[17:38] Patrick: legal stuff1 and comments from iphone, android, web browser
[17:40] Patrick: enabling public participation in the legal drafting process
[17:41] Patrick: preserve a record of not only the starting text, but the comments and the revisions and the final text

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