office-collab — archive

[Svante Schubert]

It would be optimal if we would be able to finish our specification end of this year, to allow all major ODF application vendors sufficient time to implement change-tracking in their upcoming major releases. Especially for MSO16 this would be desirable as in all previous office versions all ODF change-tracking information gets lost after loading & saving an ODF document. Therefore I would like to suggest to initiate a common start of prototyping. At least from Camilla (Calligra) and Oliver (Apache OpenOffice) I have heard that they were interested in prototyping, Jos should be curious as he created once WebODF and perhaps John might interested to test and improve compatibility to OOXML as soon as possible. In addition I do believe it would be very helpful to have face2face meetings to discuss problems on a white board and therefore I would recommend to meet informally at an ODF plugfest, other suggestions are welcome. When start prototyping I would like to drop the complexity of saving the operations and all related design decisions for the beginning. Instead I would like to focus on the design of the operations themselves and the analysis of the properties they are changing. (Sometimes an abstraction from the ODF XML is helpful as later shown for ODF lists). As discussed on our call most important for users is the insertion of text. A method signature might look like:     addText(List<Integer> startPosition, String text) NOTE: I am using Java method syntax to draft the signature of an operation, but a signature as above might be easily serialized to an explicit invocation of adding the text Hello world! to     <add type= text s= /1/1 >Hello World!</add> Text can not stand alone in an ODF document. In general text is contained in a paragraph, so we need an operation to add one:     addParagraph(List<Integer> start) for instance     <add type= paragraph s= /1 /> or for convenience in one     <add type= paragraph s= /1 >Hello World!</add> A first step, might be to create such operations with your ODF application, while loading the document ( some further details ) and using the same operations to be applied on an empty document to create the original. Some kind of round-trip through the operation domain. And when doing so, some further operations are close to obvious: A heading is only a paragraph with an outline level. The outline level just a property on the paragraph. For instance,     <text:h text:outline-level= 1 >MyHeading</text:h> would become     <add type= paragraph s= /1 outlineLevel= 1 >MyHeading</add> or as signature     addParagraph(List<Integer> startPosition, String text, Map properties) (NOTE: For ease of use, I simply add a map to the paragraph with the XML local name in camel case as key and the attribute value as map value.) Usually styles would now follow (like a nested map containing text and paragraph properties as maps), but lists are currently being discussed on the ODF TC list, I would like to ask you about lists. Lists - as discussed on our last call - can be seen as paragraphs. The question is what additional list properties are required on a paragraph to represent a list? Remember the idea is that there are only paragraphs with properties to allow an efficient transformation between heading, list-item-paragraphs and paragraphs. listStartValue - http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-text_start-value_element-text_list-item listStyle - as applied on the paragraph, the resolved list value is taken from http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-text_style-name_element-text_list http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-text_style-override and from the paragraph itself (but AFAIK widely unsupported) http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-style_list-style-name More detail see tests on OIC list -- https://lists.oasis-open.org/archives/oic/201302/msg00000.html (NOTE: The creation of the referenced list style properties should be postponed as styles in general, as it is not problematic) listLevel - the count of nested <text:list> listId - http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-xml_id consecutiveListId - as ease of use having a single property for the two ODF attributes http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-text_continue-numbering http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#attribute-text_continue-list (only expected to be on the root text:list element) showListLabel - if multiple paragraphs are within a list item, there is only a list label on the first. And if the first paragraph within a list item does not show a label it is serialized as http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-text_list-header isListStart - I am undecided about this one. Redundant if there is a listId (@xml:id). The future will tell.. The mapping is not easy, quite impossible without trying it on a living document without a prototype and therefore I need your cooperation on this. As initial draft of test documents, I may offer https://dl.dropbox.com/u/49473263/ListStyleResolution.odt https://dl.dropbox.com/u/49473263/ContinueListTest.odt https://dl.dropbox.com/u/49473263/ListStyleResolution-PreliminaryDraft.odt All valid ODF 1.2, manual edited and ContinueListTest.odt uses as well some @text:continue-list from within a list to see if some application response to it. PS: Dennis already pointed me to the OIC TC Subversion test suite repository , I will switch to that but for now the copy/paste of URLs from my local PC is far easer. But  in the future the OIC TC repository would be an appropriate place to store common test documents (Perhaps we can switch to Github, but this should be not of concern now ;) ) Best regards, Svante