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: Re: [office-collab] The Art of Mapping


Curious, what difference do you see between:

<office:text><text:p>blah, blah</text:p></office:text> and

<draw:image><text:p>blah, blah</text:p></draw:image>?

Both of those <text:p> elements are containers of text. Yes?

As a writer of documents I may put more emphasis on <office:text><text:p> as "normal" paragraphs but that's a happenstance of my work flow.

Graphic artists are like to think <draw:image><text:p> is the more important case.

If all I want to transmit is office:text/text:p/(some-change) or draw:image/text:p/(some-change), I fail to see the increased complexity of the second one? One is not simpler than the other. Yes?

Not to mention it avoids prejudice in favor of office:text, which isn't likely to find favor with people who use charts, draw, table, etc.


I will try to make the call tomorrow.

Hope you are having a great week!


On 11/29/2016 12:01 PM, Svante Schubert wrote:
I guess we all agree meanwhile that an office document as the shock frozen final state of the user's work is equivalent to a sequence of user changes creating this document.

There is an advantage to have a different view on the document, to split this monolithic complex block into changes. Changes are the 'currency' of collaboration. They are exchanged and used for merges to synchronize the paralleled work. In general, the usage of changes allows to exchange and merge minimal portions of the document, reducing complexity and in addition even enabling new features such as multiple format changes on text as discussed on last TC call.

My question to you - which I have trouble with - is how do we slice in general the features we base the changes upon?

Let me give you an example. In ODF XML every text visible to a user is within a <text:p> paragraph element. This is basically a valid design decision, but to the user (esp. to me) the paragraph within the text flow (not even header / footer) is the most important paragraph or at least a logical class for itself. Other <text:p> rather belong to other logical unit instead being one for themselves. Sometimes a <text:p> is part of the title of a frame/picture or containing the text of an annotation (i.e. being just metadata on some document portion).

The problem might become more apparent when you think of an ODF application being started to be implemented from the green field. The first step is to show text and paragraphs only (paragraph as I define them). But in general, any application might decide would part of ODF it implements and should be able to bootstrap from arbitrary features they pick from the ODF XML to create their applications, e.g. tables, images, etc.

In my "text & paragraph-only"-example we might think of the VI or Emacs (or any other text) editor that reads ODF XML and shows every paragraph as a single line showing the text of the paragraph. Likely the only the user changes of creation of paragraph and text are being send to the editor.
By this it is possible that two ODF applications with total very different feature set do collaborate. For instance, a VI/Emacs might collaborate with MSOffice / LibreOffice in theory.
The only problem would be for the user of the VI/Emacs to decide to place a paragraph/text before or after an unknown logical object. But changing/add/delete of text/paragraph in a homogeneous part works fine.

My problem is to define a rule how to realize that the <text:p> have different meanings.
I fear there is no other solution than trial and error.
Of course, it would be a good decision to slice the ODF grammer (RelaxNG) into slices defining the logical blocks (using GraphDB), but it seems in the end we need to have ODF documents using these blocks to be loaded into ODF applications to check how applications are interpreting and rendering currently those variations of elements. 

Any thoughts and/or comments?

Looking forward to exchange some ideas on this in our tomorrows call.


Patrick Durusau
Technical Advisory Board, OASIS (TAB)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau 

Attachment: signature.asc
Description: OpenPGP digital signature

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