http://www.jejik.com/feeds/tagged "odf"/atom.xmlLone Wolves (tagged "odf")Web, game and open source developmentCopyright 2010, Stichting Lone Wolveshttp://creativecommons.org/licenses/by-sa/2.5/2010-03-29T09:10:00ZPHP+SmartyStichting Lone Wolveswebmaster@jejik.comhttp://www.jejik.comhttp://www.jejik.com/articles/2010/03/officeshots_at_the_2010_document_freedom_dayOfficeshots at the 2010 Document Freedom Day2010-03-29T09:10:00Z2010-03-29T09:10:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p>Just a quick update: I will be giving a presentation about all the new features in <a href="http://www.officeshots.org">Officeshots</a> at <a href="http://www.documentfreedomday.nl/2010/index.html">the 2010 Document Freedom Day</a> in Baarn in The Netherlands. I will be updating the audience about the progress made since my <a href="http://vimeo.com/4117315">presentation last year at the DFD</a>. I am not sure exactly what time I will speak, but it will be taped for those who cannot be there.</p>
http://www.jejik.com/articles/2010/03/how_to_correctly_create_odf_documents_using_zipHow to correctly create ODF documents using zip2010-03-13T23:51:00Z2010-03-13T23:51:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p>One of the great advantages of the OpenDocument format is that it is simply a zip file. You can unzip it with any archiver and take a look at the contents, which is a set of XML documents and associated data. Many people are using this feature do create some nifty toolchains. Unzip, make some changes, zip it again and you have a new ODF document. Well… almost.</p>
<p>The <a href="http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html/OpenDocument-v1.1.html#17.4.MIME%20Type%20Stream|outline">OpenDocument Format specification</a>, section 17.4 has one little extra restriction when it comes to zip containers: The file called “mimetype” must be at the beginning of the zip file, it must be uncompressed and it must be stored without any additional file attributes. Unfortunately many developers seem to forget this. It is the number one cause of failed documents at <a href="http://www.officeshots.org">Officeshots.org</a>. If the mimetype file is not correctly zipped then it is not possible to programmatically detect the mimetype of the ODF file. And if the mimetype check fails, Officeshots (and possibly other applications) will refuse the document. This problem is compounded because virtually no ODF validator checks the zip container. They only check the contents.</p>
<p>In this article I will show you how you can properly zip your ODF files, but before I do that I will show you the problem in detail.</p>
<h4>Detecting mimetypes</h4>
<p>Linux and other Unix-like opratingsystems do not rely on file extensions to determine the type of a file. Relying on file extensions can be a serious sercurity problem, as you can see in the Windows world. It's simply too easy to change the extension and pretend that a file is of a different type than it really is. Instead, the Unix world looks at the contents of the file itself. This happens with a library called “magic”.</p>
<p>The magic library consists of a large set of rules, which it uses to figure out what type of file it is looking at. For example, it can look at a certain byte offset and see what value it contains. This is precisely the reason why the ODF specification says that you need to zip the mimetype first, without any file attributes. If you do that and open the ODF file in a hex editor, you will see something like this:</p>
<pre>Offset: Hexadecimal: ASCII:
00000000 - 50 4b 03 04 14 00 00 08 00 00 c1 b6 66 3b 5e c6 PK..............
00000010 - 32 0c 27 00 00 00 27 00 00 00 08 00 00 00 6d 69 2.'...'.......mi
00000020 - 6d 65 74 79 70 65 61 70 70 6c 69 63 61 74 69 6f metypeapplicatio
00000030 - 6e 2f 76 6e 64 2e 6f 61 73 69 73 2e 6f 70 65 6e n/vnd.oasis.open
00000040 - 64 6f 63 75 6d 65 6e 74 2e 74 65 78 74 50 4b 03 document.textPK.
...</pre>
<p>This is very easy to match for the magic library. Here is an explanation of the rules that magic uses to test if the file is an ODF file:</p>
<ol>
<li>Look at the beginning of the file. It should start with the letters PK and then bytes 03 and 04. This means it is a zip file.</li>
<li>Look at offset 30 ("1e" in hex). It should be the string "mimetype".</li>
<li>Look at offset 38 ("26" in hex), directly after the word "mimetype". It should be one of the ODF mimetypes.</li>
</ol>
<p>You can guess what happens when you don't zip the mimetype file first: The string "mimetype" won't be at the right offset. And if you accidentally zip it with extra file attributes, then the contents of the mimetype file will not start directly after it. There will be several bytes in between. This causes the magic library to detect it as a standard zip file, not as an ODF file. Here is how such a badly zipped ODF could look like. This file was zipped normally, without paying special attention to the mimetype file:</p>
<pre>Offset: Hexadecimal: ASCII:
00000000 - 50 4b 03 04 0a 00 00 00 00 00 25 01 6e 3c 00 00 PK..............
00000010 - 00 00 00 00 00 00 00 00 00 00 10 00 15 00 43 6f ..............Co
00000020 - 6e 66 69 67 75 72 61 74 69 6f 6e 73 32 2f 55 54 nfigurations2/UT
00000030 - 09 00 03 16 1b 9c 4b 47 1e 9c 4b 55 78 04 00 e8 ......KG..KUx...
00000040 - 03 e8 03 50 4b 03 04 0a 00 00 00 00 00 25 01 6e ...PK........%.n
...</pre>
<p>As you can see, it does not match the rules that the magic library has. Instead of checking your ODF file with a hex editor, you can also simply use the "file" command. For example:</p>
<pre>$ file --mime my-document.odt
my-document.odt: application/vnd.oasis.opendocument.text</pre>
<p>If that command results in "application/zip" or "application/octet-stream" then it means that your ODF file is probably incorrectly zipped. Note that the magic library shipped with "file" up to version 5.0.3 does not contain all mimetypes for ODF files but only for OpenDocument Text (odt) files. File 5.0.3 is the version most commenly shipped with Linux distributions today. I have since submitted a patch that includes all known ODF mimetypes. It was accepted and it should be included in file version 5.0.4 and later.</p>
<h4>How to zip an ODF file</h4>
<p>So, here is how you can zip an ODF file the right way. Suppose that I have an unzipped ODF file that looks like this:</p>
<pre>+ my-document/
+ Configurations2/
+ META-INF/
- manifest.xml
+ Thumbnails/
- thumbnail.png
- content.xml
- meta.xml
- mimetype
- settings.xml
- styles.xml</pre>
<p>Start by creating a new zip file that just contains the mimetype file:</p>
<pre>$ zip -0 -X ../my-document.odt mimetype</pre>
<p>The -0 parameter means that the file will not be compressed. The -X parameter means that no extra file attributes will be stored. Next you can add the rest of the files:</p>
<pre>$ zip -r ../my-document.odt * -x mimetype</pre>
<p>Be sure to exclude the mimetype file. Now if you look at it with a hex editor, you will see it has been zipped correctly:</p>
<pre>Offset: Hexadecimal: ASCII:
00000000 - 50 4b 03 04 14 00 00 08 00 00 c1 b6 66 3b 5e c6 PK..............
00000010 - 32 0c 27 00 00 00 27 00 00 00 08 00 00 00 6d 69 2.'...'.......mi
00000020 - 6d 65 74 79 70 65 61 70 70 6c 69 63 61 74 69 6f metypeapplicatio
00000030 - 6e 2f 76 6e 64 2e 6f 61 73 69 73 2e 6f 70 65 6e n/vnd.oasis.open
00000040 - 64 6f 63 75 6d 65 6e 74 2e 74 65 78 74 50 4b 03 document.textPK.
...</pre>
<p>Happy zipping everyone!</p>
http://www.jejik.com/articles/2010/01/new_officeshots_feature_odf_anonymiserNew Officeshots feature: ODF Anonymiser2010-01-05T15:55:00Z2010-01-05T15:55:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p>I have just released a new feature for <a href="http://www.officeshots.org">Officeshots</a>: The <a href="http://www.officeshots.org/pages/anonymiser">ODF anonymiser</a>.
The ODF Anonymiser tries to make your document completely anonymous
while maintaining it's overall structure. All metadata is removed or
cleaned. All text in the document is replaces with gibberish text that
has approximately the same word length and word distribution. All images
are replaced with placeholder images. All unknown content is removed.</p>
<p>The result of the anonymiser is a document that has the same general
structure but with made-up contents. If your original document does not
work in a certain application, the anonymised version of the document
should fail in the same manner. By using the anonymiser you can test
your private documents without exposing the contents to our rendering
clients.</p>
<p>To use the Anonymiser, simply check the appropriate checkbox on the
Officeshots front page.</p>
<p>The ODF Anonymiser is written and maintained by the people who created
the <a href="http://www.hforge.org/itools">iTools Python libraries</a>. The Anonymiser is part of that library
(called ODF Greek). If you want to use the anonymiser yourself, just install iTools and use the <tt>iodf-greek.py</tt> script. Many thanks for their contribution.</p>
http://www.jejik.com/articles/2009/12/new_officeshots_feature_odf_validatorsNew Officeshots feature: ODF validators2009-12-17T14:10:00Z2009-12-17T14:10:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p>I am happy to announce an exciting new feature for <a href="http://www.officeshots.org">Officeshots</a>: Integrated ODF validators.</p>
<p>Every ODF document that is uploaded is run through several different ODF validators. If the converted documents are also ODF documents (when you are testing ODF round trips) then those results are also passed through these ODF validators.</p>
<p>The results of the validators are made available on the request overview, the individual result pages and inside the galleries. Galleries now not only show all attached documents but also all results and a summary of the validator results. This way it becomes really easy to see which documents failed.</p>
<p>The following ODF validators have been integrated:</p>
<ul>
<li><a href="http://www.cyclone3.org/documentation/addons/extensions/ODFvalidator/">The Cyclone3 ODF validator</a></li>
<li><a href="http://www.probatron.org:8080/officeotron/officeotron.html">Office-o-tron</a> by Alex Brown</li>
<li><a href="http://odftoolkit.org/ODFValidator">The ODFToolkit validator</a> by Sun
</ul>
<p>Below you can see an example result of a document that has been round-tripped, showing a summary of the validation results. The one thing that show immediately is that the various validators do not always agree with each other. Documents that are valid according to one validator may be invalid according to another. Some documents (such as the result from the old AbiWord versions) can even cause some validators to choke and die with errors.</p>
<img src="http://www.jejik.com/images/officeshots/officeshots-validators-600.jpg" /><br />
<small>(<a href="http://www.jejik.com/images/officeshots/officeshots-validators.jpg">large version</a>)</small>
<p>From that page on you can click through to the individual validator outputs so you can see the complete error message.</p>
<p>Have fun!</p>
http://www.jejik.com/articles/2009/07/help_translate_officeshots_in_your_languageHelp translate Officeshots in your language2009-07-16T18:50:00Z2009-07-16T18:50:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p>I have finished setting up the internationalisation and localisation frameworks for Officeshots. If you want, you can now help to translate Officeshots to your own language. Translating Officeshots can be done through <a href="http://lang.officeshots.org">our Pootle installation</a>.</p>
<p>At the moment there are almost no languages configured yet in Pootle. The reason is that the CakePHP framework on which Officeshots runs has a different locale structure than what Pootle expects. This means I need to add every language by hand.</p>
<p>If you want to start working on a new language, please post to <a href="http://lists.opendocsociety.org/mailman/listinfo/officeshots">the Officeshots mailinglist</a> and I will add the language to Pootle and to Officeshots. Also, translations made in Pootle are not automatically pushed to Subversion or to the running Officeshots instances (because of possible merge conflicts). If you need a quick sync or push of language files, please drop a line here on the mailinglist as well.</p>
<p>Happy translating!</p>
http://www.jejik.com/articles/2009/06/fixing_opendocument_mime_magic_on_linuxFixing OpenDocument MIME magic on Linux2009-06-28T13:12:00Z2009-06-28T13:12:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p>When working on the beta of <a href="http://www.officeshots.org">Officeshots.org</a> I ran into an interesting problem with file type and MIME type detection of OpenDocument files. When a user uploads an ODF file to Officeshots I want to determine the MIME type myself using the <a href="http://www.php.net/manual/en/ref.fileinfo.php">PHP Fileinfo</a> extension. Windows user who do not have any ODF supporting applications installed will report ODF files as application/zip which is of no use to me. In addition, a malicious user could attempt to upload an executable file and report the MIME type as ODF file.</p>
<p>On Linux, the PHP Fileinfo extension relies on the magic file that is provided by the <a href="http://packages.debian.org/lenny/file">file</a> package. The magic file contains a series of tests that can determine the file type and MIME type of a file by its contents. I found out that the magic file is incomplete for OpenDocument files. Below I will show you what is wrong with the magic file and how you can fix it.</p>
<p>If you don’t care about the technical explanantion, you can <a href="#patch">skip to the fix</a> directly.</p>
<h4>The problem with magic</h4>
<p>First off, some tests. I ran these tests on Debian Lenny, but I have seen other distributions as well that have incomplete file magic support for OpenDocument Format. Here is what I get when I test an odt file using the file command.</p>
<pre>~$ file document.odt
document.odt: OpenDocument Text
~$ file --mime document.odt
document.odt: application/vnd.oasis.opendocument.text</pre>
<p>So far, so good. Both the file type description and the MIME type are right. But for any other type of OpenDocument file only the description is correct. The file type is not. Below I am testing an ods spreadsheet.</p>
<pre>~$ file spreadsheet.ods
spreadsheet.ods: OpenDocument Spreadsheet
~$ file --mime spreadsheet.ods
spreadsheet.ods: application/octet-stream</pre>
<p>The file type "OpenDocument Image Template" is even missing completely from the magic file. There is another problem with the magic file too. An OpenDocument file is basically a zip archive that contains several XML files. The <a href="http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.pdf">OpenDocument specification (pdf)</a> does not specify what version of zip to use. The magic file only searches for zip 2.0, which is what most ODF applications use, but not all. Some applications use version 1.0 instead and according to the ODF spec that is valid. Here is what happens when you try to detect an ODF file zipped with the zip 1.0 standard.</p>
<pre>~$ file document.odt
document.odt: Zip archive data, at least v1.0 to extract
~$ file --mime document.odt
document.odt: application/zip</pre>
<h4 id="patch">Fixing magic detection</h4>
<p>I have written a patch for the magic file that fixes all of the above problems. It removes the version test for the ODF zip container, adds the correct MIME type for all the different ODF file types and adds the missing OpenDocument Image Template. This patch is written for <tt>/usr/share/file/magic</tt> on Debian Lenny. If you want to patch your own Linux distribution then you may need to adapt it. You can <a href="http://code.officeshots.org/trac/officeshots/browser/trunk/server/patches/magic.patch">view the patch in our Officeshots Trac</a> or <a href="http://code.officeshots.org/officeshots/trunk/server/patches/magic.patch">download the patch directly from Subversion</a>.
<p><strong>Update 2009-06-29:</strong> I have now also created <a href="http://www.jejik.com/files/examples/file-5.0.3-opendocument.patch">a patch</a> against the original upstream <a href="http://www.darwinsys.com/file/">file-5.0.3</a>.</p>
<p>First, make a backup of your original magic file. Then apply the patch to magic.</p>
<pre>~# cd /usr/share/file
/usr/share/file# cp magic magic.orig
/usr/share/file# patch < ~/magic.patch
patching file magic</pre>
<p>After this you need to recompile the magic file. This will create magic.mgc which is the file that is actually used by the file command and the PHP Fileinfo extension.</p>
<pre>/usr/share/file# file -C magic</pre>
<p>Now your magic file will correctly identify all OpenDocument file types.</p>
<pre>~$ file --mime spreadsheet.ods
spreadsheet.ods: application/vnd.oasis.opendocument.spreadsheet</pre>
<p>And that’s all there is to it. Have fun with ODF!.</p>
http://www.jejik.com/articles/2009/05/officeshots_org_available_in_closed_betaOfficeshots.org available in closed beta2009-05-21T09:08:00Z2009-05-21T09:08:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p><a href="http://www.officeshots.org">Officeshots.org</a> has finally gone into Beta this week. It took a lot more work (and time) than expected but we made it nonetheless. At the moment the beta is a closed beta, available to current contributers and members of the OpenDoc society. But we hope to start with public, free availability within a month. Joining the OpenDoc society is free for FOSS projects, so if you are interested in the beta, please <a href="http://www.opendocsociety.org/">join them.</a></p>
<p>Below is the full press release.</p>
<h4>Officeshots.org available in closed beta</h4>
<p>"Free webservice lets user compare office applications"</p>
<p>'s Hertogenbosch/Den Haag, May 19 2009</p>
<p>The Netherlands in Open Connection and OpenDoc Society are happy to
announce the immediate availability of the beta of Officeshots.org, a
free webservice that allows users to compare the output quality of
office applications. The Officeshots project entails both an open source
service framework, and a free online service based on this framework.
The service is now in closed beta, exclusively available to members of the
international OpenDoc Society on <a href="http://www.officeshots.org">http://www.officeshots.org</a> (1). If you wish
to join the beta program you can become a member or sponsor of the OpenDoc
Society (2).</p>
<p>Officeshots.org was first announced on January 29th 2009, with the beta phase
of the Officeshots.org service scheduled to become active at the end of
February or early March. A delay in supporting rendering factories caused the
original schedule to slip but with support of NLnet, Open IT Netherlands and
Abicollab.net the project is finally ready to start the beta phase.</p>
<p>Project Lead Sander Marechal (The Lone Wolves Foundation): "At the start
of the beta phase, Officeshots.org is running a number of factories
implementing GO-OO, OpenOffice.org, Gnumeric and AbiWord. We expect to quickly
add support for a number of other factories such as Lotus Symphony, RedOffice
(Chinese), OfficeReader (an ODF viewer for Symbian smart phones) and the soon
to be released KOffice 2.0" Software vendors and user communities are
encouraged to add their office solution of choice to Officeshots.org, to make
its functionality available to a wider audience.</p>
<p>So far development work within the project has concentrated on making a
safe, distributed document rendering environment that allows buyers and
developers to test interoperability in many different applications on
many different platforms. During the closed beta the visual appearance
of the main Officeshots website will be enhanced, and a translation
framework so people can assist in translating Officeshots.org to their
native language. The beta phase is expected to last until the beginning
of June, after which the service will be available freely to anyone.</p>
<p>Officeshots will be put to the test significantly in the first ODF Plugfest
that will be held June 15/16th 2009 in The Royal Library in The Hague, where a
large number of ODF implementations (including wellknown names such as
Microsoft, Google, IBM and Sun, but also upcoming players like ZCubes and
CelFrame Office) will test their interoperability on invitation by the Dutch
cabinet in the person of Dutch Minister of Foreign Trade Frank Heemskerk (3).</p>
<p>If you wish to be updated with the latest developments and get the
announcement for the public release, please consider joining out
mailinglist at the following URL:</p>
<p><a href="http://lists.opendocsociety.org/mailman/listinfo/officeshots">http://lists.opendocsociety.org/mailman/listinfo/officeshots</a></p>
<ol>
<li>If you want to log in with a digital certificate you can do so at <a href="https://www.officeshots.org">https://www.officeshots.org</a>.</li>
<li>Join at <a href="http://www.opendocsociety.org">http://www.opendocsociety.org</a>.</li>
<li><a href="http://www.odfworkshop.nl">http://www.odfworkshop.nl</a>.</li>
</ol>
http://www.jejik.com/articles/2009/01/officeshots_org_announcementOfficeshots.org announcement2009-01-31T12:38:00Z2009-01-31T12:38:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p>Yesterday the <a href="http://www.opendocsociety.org/">OpenDoc Society</a>, the <a href="http://www.noiv.nl/noiv">NOiV (Netherlands in Open Connection)</a> and the <a href="http://www.nlnet.nl/">NLNet Foundation</a> announced <a href="http://www.officeshots.org">Officeshots.org</a>, a new webservice where you can upload ODF documents and compare their rendering and output in different office suite applications. We here at Lone Wolves are happy to announce that we are the lead architects of this new webservice.</p>
<p>Over the coming days I will announce a couple of things regarding Officeshots.org on this website, like how it works, where to get the code and how to contribute. The plan is to start a closed beta by the end of February and go public by the end of March, but if we want to make this deadline then we need contributers. In the upcoming days I will explain exactly what we need, but if you want to help then you can already <a href="http://lists.opendocsociety.org/mailman/listinfo/officeshots">join the officeshots.org mailinglist</a>.</p>
<p>Here is the full press release from the OpenDoc Society and NoiV:</p>
<pre>Free webservice lets user compare office applications
'Office users can finally see what others are seeing'
~ Maarssen/Amsterdam, The Netherlands, January 30th 2009
The Dutch government program "Netherlands in Open Connection" and
OpenDoc Society have announced they are collaborating on an online
document factory to compare office suite applications. The free
webservice Officeshots.org should be available by the end of February
2009. Users will be able to online compare the output quality of a large
number of office suites as well as web-based productivity applications.
The collaboration was announced during a well visited ODF conference in
Maarssen, The Netherlands. The project is financially supported by a
grant from the Netherlands based not-for-profit investor NLNet Foundation.
"Thanks to the adoption of open standards like the Open Document Format,
the number of productivity applications is increasing rapidly. In a
mature market a user should be able to compare the various suppliers
transparently." says Bert Bakker, president of the OpenDoc Society.
"Officeshots.org will ensure that you do not need to blindly trust a
supplier when he claims to support a certain document format. Seeing is
believing."
"We want to make the differences between the various applications
visible and measurable, which will stimulate suppliers to make quality
improvements" said Ineke Schop, program manager at Netherlands in Open
Connection."Because a user can simply upload a document and see the
output of the various applications they get a powerful tool to make
quality differences measurable. The service also helps designers to
compare the rendering of document templates and letterheads in different
office suites. "This helps governments choose the right application and
supports the ambitions of the Dutch cabinet to standardise on ODF and
PDF for document exchange."
Under the "Netherlands in Open Connection" action plan, the Dutch
administration accepts and uses the Open Document Format as of April
last year. Other government bodies in the Netherlands do so since
January 2009. The program is a joint initiative of the Dutch government,
led by the minister for Foreign Trade Heemskerk and the State Secretary
for the Interior and Kingdom Relations Bijleveld-Schouten.
The tool will be multilingual from the start. The web service will
launch as a closed beta for members of the OpenDoc Society at the end of
February, followed by a public launch planned one month later.</pre>
http://www.jejik.com/articles/2008/11/where_knowledge_is_freeWhere knowledge is free2008-11-13T08:56:00Z2008-11-13T08:56:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p>I just spotted this wonderful poem about freedom on a photograph of the <a href="http://www.odfolympiad.org/malaysia">ODF Olympiad 2008 Malaysia</a>. I thought it very apt for the issues facing us these days.</p>
<blockquote>
<p>Where the mind is without fear and the head is held high.</p>
<p>Where knowledge is free.</p>
<p>Where the world has not been broken up into fragments by narrow domestic walls.</p>
<p>Where words come out from the depth of truth.</p>
<p>Where tireless striving stretches its arms towards perfection.</p>
<p>Where the clear stream of reason has not lost its way into the dreary desert sand of dead habit.</p>
<p>Where the mind is led forward by thee into ever-widening thought and action-into that heaven of freedom, my Father, let my country awake.</p>
<p style="text-align: right;"><em>Rabindranath Tagore</em></p>
</blockquote>
<p>Via the <a href="http://lists.opendocumentfellowship.com/mailman/listinfo/odf-discuss">ODF Discuss mailinglist</a>.</p>
http://www.jejik.com/articles/2008/04/109Sinclair's Syndrome2008-04-19T12:50:00Z2008-04-19T12:50:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p>A curious <a href="http://www.iso.org/iso/pressrelease/faqs_isoiec29500.htm">FAQ</a> put up by an unnamed ISO staffer on MS-OOXML. Question #1 expresses concerns about Fast Tracking a 6,000 page specification, a concern which a large number of NB's also expressed during the DIS process. Rather than deal honestly with this question, the ISO FAQ says:</p>
<blockquote>The number of pages of a document is not a criterion cited in the JTC 1 Directives for refusal. It should be noted that it is not unusual for IT standards to run to several hundred, or even several thousand pages.</blockquote>
<p>For ISO, in a public relations pitch, to blithely suggest that several thousand page Fast Tracks are "not unusual" shows an audacious disregard for the truth and a lack of respect for a public that is looking for ISO to correct its errors.</p>
<p>From: <a href="http://www.robweir.com/blog/2008/04/sinclairs-syndrome.html">An Antic Disposition</a> by Rob Weir.<?p>
http://www.jejik.com/articles/2008/03/a_response_to_patrick_durusau_who_loses_if_openxml_losesA response to Patrick Durusau: Who Loses If OpenXML Loses?2008-03-26T09:22:00Z2008-03-26T09:22:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p><strong>Updated on 2008-03-26@17:34</strong> I emailed a copy of this article to Patrick and he has responded. I have posted his response <a href="#patrick-response">below</a>.</p>
<p>This is a response to Patrick Durusau's recent letter <a href="http://www.durusau.net/publications/wholoses.pdf">Who
loses if OpenXML loses? (PDF)</a>. Before I discuss the various points that you make in your letter there is one thing that
I would like to say; I find it shameful that you, Patrick, makes these kind of statements without a proper disclaimer that
this is your personal opinion and not the position of the ODF committee (for whom you edit the ODF specifications), the V1
or any other technical body that you represent. In fact you seem quite happy that the media is running with headlines like
“The ODF editor says…” else you would have done something about it after your
<a href="http://www.robweir.com/blog/2008/03/contra-durusau-part-1.html">previous publications</a>. To lead by example:</p>
<p>The opinions expressed in this letter are my own. They do not necessarily represent the viewpoint of LXer Linux News, nor
the viewpoint of my employer <a href="http://www.tribal-im.com">Tribal Internet Marketing</a>. They do represent the viewpoint
of <a href="http://www.jejik.com">The Lone Wolves Foundation</a> though.</p>
<p>Now, back to your letter.</p>
<blockquote>1) National bodies lose an open and international forum for further work on DIS 29500.</blockquote>
<p>Which open and international forum? DIS 29500 is scheduled to be <a href="http://www.jtc1sc34.org/repository/0885.pdf">maintained
by Ecma (PDF)</a>. Office Open XML is already an Ecma standard: Ecma 376. So the community can already work with Ecma on
future revisions of that standard. Approving DIS 29500 does not change the venue in any way. It only changes the name of the standard.</p>
<p>The only circumstances under which this statement can be true is if Microsoft has announced to stop supporting Ecma 376 all together unless
it is approved as DIS 29500, but promises to work on the standard if it does get the ISO stamp. This is obviously not true because
Microsoft has already stated that it cannot commit to whatever comes out of Ecma, regardless if it's DIS 29500 or Ecma 376 they
are working on. From the mouth of <a href="http://blogs.msdn.com/brian_jones/archive/2007/07/12/spreadsheet-formula-bugs.aspx#3850252">Brian
Jones</a>:</p>
<blockquote>it's hard for Microsoft to commit to what comes out of Ecma in the coming years, because we don't know what direction
they will take the formats. We'll of course stay active and propose changes based on where we want to go with Office 14. At the end
of the day though, the other Ecma members could decide to take the spec in a completely different direction.</blockquote>
<p>Your point can also be interpreted in a different way. Perhaps you are arguing that Ecma is no open forum but only ISO is. If that is true
then it's obvious that DIS 29500 should not be maintained by Ecma if it is approved. It would also mean that Ecma 376 is nothing more
than a rubber stamp on a stack of documents submitted my Microsoft and that Ecma 376 should never have entered the fast track process
in ISO. I'd go further and state that if Ecma is not an open forum then it should be barred from the fast track process at ISO all together.</p>
<p>Your second point makes little no no sense at all:</p>
<blockquote>2) Microsoft based third-party vendors may be excluded from contracts because Microsoft has no ISO approved format.</blockquote>
<p>First: ISO and its national bodies do not owe any company a living. Second: There are no third-party vendors that implement DIS 29500. The
best you get is a few third-party vendors that support a few parts of Ecma 376. Third: The primary concern for third-party vendors is
interoperability with Microsoft Office. They can already interoperate with Microsoft Office by implementing Ecma 376. DIS 29500 adds nothing
in this regard.</p>
<p>What you are really saying is that not appriving DIS 29500 means that Microsoft itself will lose out on certain contracts. This has some
effect on third-party vendors as well of course. If some company or government body does not use Microsoft Office then they will not have much
need for third-party tools that implement Office Open XML. Again the answer is simple: ISO does not owe Microsoft a living.</p>
<p>But the point above is of course why Microsoft is trying to ram Ecma 376 through ISO in the first place, isn't it? If Office Open XML does
not have an ISO stamp of approval and OpenDocument Format does, then it's plausible that government bodies over the world will mandate ODF
support in their IT procurements. Since Microsoft is not willing to implement ODF support in Microsoft Office it's very likely that
Microsoft Office cannot fulfill those procurements. Yet again the answer is simple: Governments do not owe Microsoft a living. It's Microsoft's
problem and not the government's problem. Microsoft can easily avoid this situation by implementing full support for ODF in their
Office suite.</p>
<p>Proof of my point can easily be seen in Microsoft's requirements that any change that ISO or Ecma make to DIS 29500 does not break support
for Office Open XML as currently implemented in Microsoft Office 2007. From <a href="http://www.openmalaysiablog.com/2008/03/geneva-day-five.html">Yoon
Kit on the OpenMalaysia blog</a>:</p>
<blockquote>We eventually found out that if any changes affected current implementations it would certainly be rejected.</blockquote>
<p>If Office Open XML passes ISO certification but its specification is incompatible with Microsoft Office 2007 then Microsoft will have gained
nothing. Governments will procure for ODF or OOXML support but since Microsoft Office 2007 then does not implement either, it still cannot
fullfill the procurement. This is the sole reason for DIS 29500: Maintaining the Microsoft Office cashcow. On to your third point:</p>
<blockquote>3) ODF has no ISO-based formula definitions to insure compatibility between OpenDocument and OpenXML.</blockquote>
<p>Approving DIS 29500 does not change this in any way. OpenDocument Format 1.2 is already on its way and it will handle spreadsheet
formulas in its own way. What is needed here is a mapping between Ecma 376 and ODF 1.2 spreadsheet functions. DIS 29500 does not contain this
mapping. Moreover, we do not need DIS 29500 to create this mapping. We can create it from Ecma 376.</p>
<blockquote>OpenDocument currently lacks formula definitions for spreadsheets. (To appear in OpenDocument
1.2.) Many core financial functions in spreadsheets are undefined except for actual Excel output. That
output varies by version and service pack of MS Office. What happens if OpenDocument and
OpenXML reach different definitions of those functions?</blockquote>
<p>This makes using Excel for financial calculations outright dangerous. It's a big vote against Microsoft Office. And if all those
variations and inconsistencies are in the DIS 29500 specification then it's a big vote against DIS 29500 as well.</p>
<blockquote>4) ODF has no ISO-based definition of MS legacy features for an ODF extension.</blockquote>
<blockquote>OpenDocument does not presently support legacy features of Microsoft formats. That will be easier
with a formal definition of those features. Without OpenXML, OpenDocument has no authoritative
definition of those legacy features. That delays OpenDocument supporting them in some future release.</blockquote>
<p>DIS 29500 does not need to be approved for this. Ecma 376 as it stands already formally defines these features. If DIS 29500 does not
pass ISO then Ecma 376 is authorative. OASIS and ISO can use Ecma 376 to create possible extensions to ODF.</p>
<blockquote>5) ODF has no ISO-based definition of the current MS format for mapping purposes.</blockquote>
<blockquote>OpenDocument does not have a robust mapping to the current Microsoft format. That requires an
OpenXML that has completed the standards process. If OpenXML is unclear, it must be fixed in order
to create a robust mapping between the two.</blockquote>
<p>First: DIS 29500 does not provide such a mapping. The current Micrsoft formats are the binary formats. What is required is a
mapping for those binary formats. Second: If such a mapping is ever made then there is still no need for DIS 29500. Ecma 376 is good
enough for that. Third: If Office Open XML is unclear and needs fixing then it should be disapproved now. That way Ecma can resubmit
it through the normal (non fast-track) ISO process where enough time can be spent fixing it. Fast track is no place for a flawed standard.</p>
<blockquote>The bottom line is that OpenDocument, among others, will lose if OpenXML loses.</blockquote>
<p>The only one who loses if DIS 29500 fails is Microsoft, whose Office 2007 cashcow will run into trouble. Everyone else, including the
OpenDocument Format, do not need an ISO stamp of approval on DIS 29500. The current Ecma 376 standard, flawed as it is, is more than enough to work
with. Putting an ISO stamp of approval on that document does not suddenly make it “more interoperable” or a better spec. Unless
Microsoft stops working with Ecma, but that is not ISO's problem. It's Microsoft's and Ecma's problem. Besides all that, Ecma can still resubmit
Ecma 376 through the regular ISO process and gain approval in a few years when the standard has been properly reviewed and fixed. That's too late
for the Microsoft Office cashcow of course, but that is not ISO's concern.</p>
<p>The world does not need DIS 29500. Ecma 376 currently provides the exact same benefits well enough.</p>
<p id="patrick-response"><strong>Update</strong>: Patrick Durusau has sent me a response to this article:</p>
<blockquote>
<p>Sander,</p>
<p>Since I have spent the last six years of my life working on and improving the ODF standard I feel no need to formally respond to your obviously ill-informed post.</p>
<p>I have spend the last six years working on ODF, posting corrections to every version, leading the new metadata work, and now work as the TC editor. I don't have to answer questions about my commitment to ODF from you or anyone else.</p>
<p>You can publish that as my response if you like.</p>
<p>Patrick</p></blockquote>
<p>So posted.</p>
<p><em>This letter is also posted on <a href="http://lxer.com/module/newswire/view/101017/index.html">LXer Linux News</a>.</em> <a href="http://digg.com/microsoft/A_response_to_Patrick_Durusau_Who_Loses_If_OpenXML_Loses"><img src="http://digg.com/img/digg-it-tiny.gif/" alt="This article on Digg"></a></p>
http://www.jejik.com/articles/2008/01/odf-xslt_project_announcementODF-XSLT Project Announcement2008-01-10T10:34:00Z2008-01-10T10:34:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p>Lone Wolves is happy to announce the <a href="http://www.jejik.com/odf-xslt/">ODF-XSLT project</a>. The ODF-XSLT Document Generator is a library written in PHP 5 that brings the full power of
XSLT to your OpenDocument files. It enables you to use ODF files as if they
were plain XSLT templates. It also includes a few extra parsing options that
allow you to edit the XSLT parts of these ODF from within your favourite office
suite. ODF-XSLT is developed by <a href="http://www.tribal-im.com">Tribal Internet Marketing</a> and is released by Stichting Lone Wolves as Free Software under the GNU General Public License, version 3.</p>
<p>The first release of ODF-XSLT is <a href="http://www.jejik.com/files/odf-xslt/odf-xslt-0.4.tar.gz">odf-xslt-0.4</a> and can be downloaded from our <a href="http://www.jejik.com/odf-xslt/download/">download section</a>, together with a nightly snapshot of the subversion trunk. You can also check out the latest version directly from our <a href="http://svn.jejik.com">subversion repository</a>. The manual and API documentation are available from the project website.</p>
<h4>Features</h4>
<ul>
<li>Based on the industry standard (ISO/IEC 26300) OpenDocument format.</li>
<li>Multiple document types supported (text, spreadsheet, etcetera).</li>
<li>Full XSLT support. Since XSLT is <a href="http://www.idealliance.org/papers/extreme/proceedings//html/2004/Kepser01/EML2004Kepser01.html">Turing-complete</a>, anything is possible (in theory).</li>
<li>Templates can be edited from within your office suite, such as OpenOffice.org or KOffice 2.</li>
<li>Easily extensible by hooking in pre- and postprocessors.</li>
</ul>
<h4>Requirements</h4>
<ul>
<li>PHP 5.2 or later</li>
<li>PHP CLI for the commandline utility</li>
<li>libxslt and the PHP XSL extension</li>
<li>zlib and the PHP Zip extension</li>
</ul>
<h4>Acknowledgments</h4>
<p>Many thanks to Heini van Bergen from Tribal Internet Marketing for allowing
ODF-XSLT to be released as Free Software. Also thanks to Mirko Nasato who's
<a href="http://www.artofsolving.com/opensource/jodreports">JODReports</a> software was a big inspiratrion for ODF-XSLT.</p>
<h4>About Lone Wolves</h4>
<p>Stichting Lone Wolves is a small not-for-profit development company based in The
Netherlands. We create websites for small to medium sized businesses and use the
profits to fund our free software projects such as gnome-hearts and ODF-XSLT.</p>
<h4>About Tribal Internet Marketing</h4>
<p>Tribal was established in 1999 and since then started offering full-service
internet solutions. Tribal Internet Marketing (IM) is, in conjunction with
Tribal Internet Solutions (IS), a division of Tribal BV and is one of the top
specialized search engine marketing agencies in the Netherlands.</p>
http://www.jejik.com/articles/2007/06/the_legend_of_the_rat_farmerThe Legend of the Rat Farmer2007-06-05T05:39:00Z2007-06-05T05:39:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<blockquote>A long time ago in a land far away there once was a prosperous town called Hamelin. Everything was perfect in Hamelin until the year the rats came. The rats ate up the grain, bit the townsfolk in the toes and scared the young children. Something had to be done!</blockquote>
<p>And so begins Rob Weir's allegory <a href="http://www.robweir.com/blog/2007/05/legend-of-rat-farmer.html">The Legend of the Rat Farmer</a>. An allegory in which the Bürgermeister and Council of Hamelin try to find a solution to their rat problem, discover the importance of appropriate metrics and learn a thing or two about standardization in the process.</p>
<p>Rob gives a very good explanation of exactly what is wrong with Microsoft's latest claims that “choice [of standards] is good for the consumer”. Read it at <a href="http://www.robweir.com/blog/2007/05/legend-of-rat-farmer.html"> An Antic Disposition</a>.</p>
http://www.jejik.com/articles/2007/01/52IT standards hijack threatens European economic competitiveness2007-01-26T07:15:00Z2007-01-26T07:15:00ZSander Marechals.marechal@jejik.comhttp://www.jejik.com
<p>Two organisations, OpenForum Europe (OFE), a leading organisation set up to advance the use of open standards, and ODF Alliance, a campaigning group promoting open document format, representing over 210 organisations in 30 countries, highlight that the new standard, Microsoft licensed Office Open XML, is being fast tracked to become a new European ISO/IEC standard. This new standard has been submitted by ECMA, the European Computer Manufacturers Association with a completely unrealistic deadline for stakeholders to engage.</p>
<p>One of the OFEâs and ODF Allianceâs main criticisms targeted at ECMAâs standard is its complexity. It is over 6,000 pages long, excluding supporting material, making it time consuming and ultimately more expensive for the future development of software. It also duplicates an existing comprehensive and recently ratified) standard Open Document Format (ODF) which causes a major issue of system complexity, development, maintenance, archiving and licensing. Furthermore, elements of ECMAâs standard contradict the recently ratified ODF standard, which if implemented, would lead to confusion for software developers, increase cost and leading to problems sharing and archiving documents. There are also serious doubts that the standard could be implemented outside the Microsoft environment, due to license requirements that are not made explicit.</p>
<p>ACTION: Write to your local standards organisation setting out your concerns, recommending that an issue of this importance should be reasonable given time for proper consideration and due diligence. A 30 day Fast Track Procedure is not appropriate for a 6000 page document. Contact list on the ODF Alliance European Website.</p>
<p>From: <a href="http://sourcewire.com/releases/rel_display.php?relid=29267&hilite=">SourceWire</a></p>