Document file format

Yesterday my wife received a request for a poll by email. She confirmed to participate and received ... - a Word document. Not a link to a website, not a PDF form, not a text file - no, a Microsoft Word document with form fields. And we are on Linux.

Although Open Office does a great job on importing Word documents some form fields (meant as a pull-down menu) did not show up the available alternatives). My wife told me and said she thinks that initially somehow something showed up for a moment. I have to say, that I had no interest in investigating this problem, because of a single reason:

People should write documents in a portable, platform independent standard format.

Especially when intended for large amount of people it is important to use a format that can be displayed (and edited where necessary) by everybody.

I had an interested talk a few years ago with a project manager who also teaches and trains other project managers about the format of documentation created during a project. He told me that prior to a project start they analyze the environment at the different partners involved and if they use different versions of Microsoft Office products then they estimate higher project costs due to compatibility issues because different versions of Microsoft Office behave differently and display contents differently. They often use the RTF format to overcome different drawbacks. However, using RTF reduces available formatting features.

I know these problems also. Not only once a co-worker wasted half a day correcting the layout of a concept that has been written as a Word document and has been edited by a customer.

So already years ago I switched to Open Office for every project relevant documentation. After evaluating the options that sounds the best alternative for me using the Open Office formats ODT, ODS and ODG.

The major advantages are:

• Platform independency
  I can read and edit the documentation at work under Windows and at home with Linux.
  
  
• No (or at least very few) compatibility issues.
  Using different platforms or versions of Open Office does not raise display or layout issues - or at least not with the amplitude known from Microsoft Office.
  In the past for major changes in the document features Open Office did change file extension keeping compatibility and transparency.
  
  
• No license fees
  Open Office is free and would also help companies saving a lot of money.
  
  
• Direct PDF creation with bookmarks and links
  Open Office can directly create PDFs (without the use of an external PDF printer driver) Preserving links from table of contents or other links within the document. Further (when using appropriate heading format templates) bookmarks are automatically created in the resulting PDF which makes navigation easy when reading the document online.
  

For mind mapping I also use FreeMind which is a good supplement when writing project documentation.

Especially in IT or more technic/industry focused companies there are other types documents also to be written that cannot be written efficiently using Open Office. For those cases I recommend looking at OSALT.COM. That site helps finding alternative Open Source software for different commercial products. - E. g. DIA as an alternative for Visio (although - with some limitation - Open Office Draw can be used also). The Open Source alternatives do not always offer the same huge feature set as some commercial product, so there are sometimes relevant limitations. But in other cases the

Related posts: Data file format, Why I hate ribbons, Stationary under Ubuntu, Ignorance of the different, Popular Ubuntu desktop myths.

Data file format

Initially the XML format was a hype. It was praised for it's flexibility, human readability (clear text) and praised to be the ultimate solution for every export and import problem. Although it is true that this format can be used for many different things I never liked it.

The format is flexible, that is true, but other advantages are myths:

• Human readability:
  Yes, it is a text format. But from the practical view it can be very difficult to get an overview in a bigger file. This because without an appropriate tool matching opening and closing tags are not obviously if the text is not really well formatted.
  
  
• Data Exchange (import, export and application interoperability):
  That the XML format is very flexible is a disadvantage here but as any common format has to be flexible we cannot see this as a disadvantage here. The problem is different: No matter which format you are using you always need additional definitions on the tags, columns, sections or whatever - which elements are required, which are optional and what exactly are the allowed values. For application interoperability you always need a detailed specification on how the format is used and which elements. So the file format itself can never be a general solution.
  
  
• Simple and efficient:
  Although the general rules are simple there are a lot of additional optionals like specifying DTD, parameters of tags or XML headers. But when I once tried to write a parser for XML you know that there cannot be an algorithm with real good performance on reading XML. Parsing other formats like CSV, INI and so on will always be faster. You need to use existing libraries that do that parse the XML for you if you have to achieve your goal quickly. Further XML cannot be efficient just from the character overhead. XML is simply big.

What developers already noticed has not yet been really broadcasted but there already have been created alternatives like YAML and JSON. Both formats are very easy to learn, very easy human readable, easy to create and easy to parse. And further they produce smaller files and hence produce less traffic. So I think those formats should be more enphasized in the future. However a lot of people are still betting on XML...

An argument for XML could be the possibility to specify element types and so on. Well, in any case there must be a business logic checking the input (in whatever format) for it's validity. I do not think that all type validation can be done through XML definitions. As there might be code logic involved also it is better to have only one place where checks are done.

Related post: Document file format, Ignorance of the different.