Successfull deployment of OpenOffice in the public sector.

I had the opportunity to participate at the MAMPU conference on Successfull deployment of OpenOffice in the public sector in Kuala Lumpur, Malaysia.



It was great.

The general arguments I tried to make in my talk where around the following matrix:



The argument I derived from that matrix where

1. clearly a shift from an open source application with a proprietary file format to an open source application with an open standardized file format improves openess.
   
2. however how can a shift from a proprietary application with a proprietary file format to a proprietary application with an “open” file format improved openess? And --- is it the same kind of “openess” as in case 1)?
   

I then made the argument that only an open source application with an open file format can prevent a “lock-in” situation. I illustrated the fact by a case study of supporting a “minority language”.

So --- how would you fill out the matrix?

Note: This element should not be used in new documents.

I still got a lot feedback regarding the use of the word „deprecated“. So please let me explain what I had in mind when I wrote this.

In the current ODF specification there is the following note in section 6.6.11 Table Formula Field. It says:

Note: This element should not be used in new documents.

My idea was simply to add a similar note to e.g. section 8.2.6 Subtables.

So again there are already features in ODF marked as "not to use".

Hi Mathias,

thanks so much for referring to my blog and commenting on my "ODF 1.2 suggestions".

Yes --- I really believe we can work together making OpenDocument as well as OpenOffice.org better.

Regarding “deprecation”. Deprecation does not mean removal or even making OpenOffice.org worse. Never intentend to say this. Sorry for the confusion. What I meant was e.g. in the case of “sub tables” that "deprecation" or "discourating" the use of "sub tables" just means helping e.g. blind people to better use OpenDocument and OpenOffice.org: Subtable Accessibility Issue.

Of course the feature will stay, but I think we should offer the user an alternative way to achieve the same result and help --- not only accessibility --- but also interoperability.
Luckily OpenDocument has this feature already by using “row spans”.

I hope I could also clarify Michael Brauers concerns on the the OpenDocument TC mailing list with my response.

But I think we have the same idea here. Will never again use the word "deprecation" or "discourage" again. And I will not take away any feature. Promised!


~Florian

Suggested enhancement for OpenDocument V1.2

Tables:
* introduce allowCollapse attribute for paragraphs following nested tables to encode WW and HTML-like tables.
* declare sub tables as deprecated

Numbering
* introduce text:level-text attribute to encode arbitrary number formats
* introduce text:num-follow-char to encode WW-like numbering
* introduce text:list-override to encode WW-like numbering
* declare style:list-level-properties/@text:space-before as deprecated. Effect can be achieved with paragraph indent.

Master-page styles
* add header-first and footer-first to encode WW-like page-styles
* modify master-page styles such that WW-like sections can be encoded; current CSS3.0 like text:sections are not applicable
* declare the style:next-style-name attribute of master-page declarations as deprecated.

Styles:
* allow deriving paragraph-family styles from text-family styles.

“Break chars”
* introduce a <text:page-break/> command and a <text:column-break/> command similar to the <text:line-break/> command

Fields:
* enhance field support by introducing a <text:field-start/> and a <text:field-end/> element to which metadata can be attached.

Change tracking:
* introduce change tracking for tables
* introduce change tracking on property level

Discourage the use of the following OD features for MOOX interop:
* nested frames
* current CSS3.0 like text:sections
* use fo:break-before instead of fo:break-after
* use fo:margin-* for tables

Unfortunately I think this list is not complete yet:-)

Feedback appreciated.

All the small things…

…are really important in document conversion. The table below shows three different ODF features (numbered lists, nested styles as well as nested tables) and the way OpenOffice.org Writer resp. the CleverAge ODF Converter exports these.

Original ODF in OO.o	OO.o export to .DOC	CleverAge ODF Converter

The above examples look rather artificial. However these kinds of small problems can tell much about the conversion quality of a filter.
For example handling nested styles correctly is a huge effort for a rather small output. Thus everybody ignores them in the first shot and aims for the more visible features. You simply file a bug and set it to “later”.
The problem is when “later” comes you realize that handling nested styles requires major changes in your existing code. You then realize that the risk of loosing all your existing features by implementing nested styles is high. So “later” becomes a synonym for “never”.

In my opinion a good test for the underlying code quality of a conversion filter is to test the nasty stuff. I believe it can tell you a lot about whether “later” means “never” or simply “not yet”.

Btw. all the above features can be mapped correctly.

So I started blogging. This is the first entry of my personal blog.

So there is a lot to clarify. But first let me provide some background to those who don’t know me.

I’ve done some work in the past on the .DOC, .RTF and WordML filters in OpenOffice.org. I also did some work on OpenDocument in the OpenDocument TC and the OpenDocument Metadata SC.

I also worked together with the OpenDocument Foundation on the ODF plug-in for Microsoft Office. The ODF plug-in for Microsoft Office is based on a library called OpenDocument Infoset API I was working on. Of course I’ll continue my voluntary work as a CTO of the OpenDocument Foundation and I’m eager to see how the Foundation’s work --- especially on the OpenDocument InfoSet API --- will continue. I’m happy to tell more about this in following blog entries if there is any interest.

What I discovered in all my work regarding the fileformats is that interoperability can be improved. In fact minor changes in the fileformats resp. implementing applications can improve interoperability significantly. And I hope I can prove this with my future work.

So what is this future work?

One very interesting area is OpenDocument Version 1.2. Currently the OpenDocument TC is working on the version 1.2 of OpenDocument which targets better interoperability. Very interesting and with great potential.

Another interesting area is OpenOffice.org. I really believe we can improve OpenOffice.org’s interoperability by implementing OpenDocument Version 1.2 in OpenOffice. This is a community effort for sure, so I hope I can attract people participating in this effort.

Maybe the next thing I should do is to have a little tutorial about how to contribute to the OpenOffice.org filters? Good idea?