Re: [office-collab] food for comparison: operations in webodf

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

Hi,

Thanks for the information, Jos and a belated Happy New Year to all of you.
Please read my comments below.

Am 18.12.2013 16:31, schrieb Jos van den Oever:

Hi list,

For inspiration, I thought I'd summarize part of the approach we are currently taking with regards to operations in WebODF. All of our current operations are located in one folder. 

I do like the separation/bundling into a directory.

Operations are performed by users that each have a memberid that is unique within a session.

Wouldn't be possible to re-use the users defined in the meta.xml? Arn't they identical? Do we need or want redundancy?

In our current implementation, operations are sent as JSON objects. Each operation object has a timestamp and memberid.

The JSON Serialization is the serialization for the web, although I already added a section of JSON definition for the operations, I do think to have a mapping to XML and story XML into our ODF package to keep the tool/science level low.

Members and Cursors

In WebODF, the object that is being edited is a session. A session consists of an ODF document and a number of members with or without a cursor. The cursor represents the member in the session. So the member cursors are part of the shared state.

A member can join a session with OpAddMember(memberid, setProperties). The setProperies argument is a dictionary object with information about the member. A member may leave with OpRemoveMember(memberid).

A members cursor can be part of the session but outside of the document. By calling OpAddCursor(memberid), a cursor is added to the first position in the document. A cursor can be removed from the document with the operation OpRemoveCursor(memberid).

To place the cursor at a certain position within the document, the operation OpMoveCursor(memberid, position, length, selectionType) can be called. Since each member has one cursor, the memberid identifies the cursor. The position is a number that indicates a position within the document. A position in combination with a length larger than zero is a selection. The value of length gives the size of the selection. Selections come in two flavours: Region and Range. A Region single frames completely and a Range corresponds to anything else.
The position system is different from what is currently proposed in ODF Collab, which uses an array of container positions. These systems are interchangeble.

The above is quite related to the run-time behavior, still very interesting for the serialization are the session and the cursor position.

Cursor position

AFAIK it is currently partly implementation dependent, I could not find by try and error a settings.xml cursor related element, but I remember I have seen such thing once. The common way, what I have never seen before in XML is to use an inline XML processing instruction. In our ODF 1.2 specification the following is written:

3.11 Cursor Position Setting

To represent a text cursor position within a document, a processing instruction with PITarget opendocument (see §2.6 of [XML1.0])should be used. The name of the cursor position processing instruction, cursor-position, shall follow the PITarget opendocument. The processing instruction may have arbitrary implementation-defined attributes.

Note: Where a text cursor position is not sufficient to recreate a document view, producers may use arbitrary document specific settings in addition to a cursor position processing instruction.

Having a reference schema by components will allow not only to have an inline XML processing instruction, but to have an element with an attribute having the path of the cursor.
It might make sense to save this data with the user (e.g. meta.xml) as cursor are user dependent.

Session

How does an ODF application know when a session starts/ends or might have a mile stone?
Perhaps some one the list have some ideas on that?

Styling

Direct styling can be applied to a document with OpApplyDirectStyling(position, length, setProperties). The position and length have the same definition as in OpMoveCursor.

The setProperties styling information is an object similar to a flattened <style:style/> element. For example, to specify bold text, send the object {text: {font-weight: "bold"}}.

The latter seems identical as in the current draft, the former has a length instead of a second position, which is just a different form of providing the information.

Thanks for your feed-back, Jos!
Has any other a comment on this?

Best regards,
Svante

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php