<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The OOXML bunch is boringly disappointing.</title>
	<atom:link href="http://standardsandfreedom.net/index.php/2008/01/19/the-ooxml-bunch-is-boringly-disappointing/feed/" rel="self" type="application/rss+xml" />
	<link>http://standardsandfreedom.net/index.php/2008/01/19/the-ooxml-bunch-is-boringly-disappointing/</link>
	<description>A weblog by Charles-H. Schulz.</description>
	<lastBuildDate>Mon, 26 Jul 2010 17:53:22 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Boycott Novell &#187; Quick Mention: The Latest OOXML Stunt Dissected, Trashed</title>
		<link>http://standardsandfreedom.net/index.php/2008/01/19/the-ooxml-bunch-is-boringly-disappointing/comment-page-1/#comment-573</link>
		<dc:creator>Boycott Novell &#187; Quick Mention: The Latest OOXML Stunt Dissected, Trashed</dc:creator>
		<pubDate>Mon, 21 Jan 2008 06:34:24 +0000</pubDate>
		<guid isPermaLink="false">http://standardsandfreedom.net/index.php/2008/01/19/the-ooxml-bunch-is-boringly-disappointing/#comment-573</guid>
		<description>[...] is one rebuttal to Microsoft&#8217;s claim that its formats will be more open.  First there is that “oh, we forgot we never gave you the specs of our binary file format” [...]</description>
		<content:encoded><![CDATA[<p>[...] is one rebuttal to Microsoft&#8217;s claim that its formats will be more open.  First there is that “oh, we forgot we never gave you the specs of our binary file format” [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephane Rodriguez</title>
		<link>http://standardsandfreedom.net/index.php/2008/01/19/the-ooxml-bunch-is-boringly-disappointing/comment-page-1/#comment-571</link>
		<dc:creator>Stephane Rodriguez</dc:creator>
		<pubDate>Sun, 20 Jan 2008 13:49:54 +0000</pubDate>
		<guid isPermaLink="false">http://standardsandfreedom.net/index.php/2008/01/19/the-ooxml-bunch-is-boringly-disappointing/#comment-571</guid>
		<description>&quot;What I mean by OOXML being half smaller is this: if we had access to the full specs of the binary file formats, then the claim that OOXML has to represent past layouts and behaviours&quot;

I understand what you mean now. But if Microsoft had to document every single detail of implementation of the binary format, the only way they would be able to do that would be to open up the source code. Indeed, the binary format specs that have been provided in the past are bare references (just like OOXML, bits are described with short sentences, and so on).

I think it&#039;s fair to say that OOXML is not compelling as a standard since it&#039;s just the binary formats with angle brackets. (to be honest they&#039;ve added a few things, but nothing substantial : even their so-called &quot;great&quot; custom XML schemas were available in Word 2003 already).

I think that all the noise they made with their new user interface (Ribbon) was a PR scam to try to make IT people think that Office 2007 is really something new and worth upgrading it, even though that was just a change on the surface. That&#039;s things like this that should be rebutted. But the Microsoft bulldozer is very powerful : no matter how right we are, they have the money to communicate much more effectively to their target customers (through PR wire).

As for OOXML versus ODF, I think it&#039;s indeed the case that OOXML as we know it does not help the workplace and should be dismissed. We know that Microsoft chose not to work with the OASIS TC just because it was not their stuff, and being the paranoid freaks that they are, they try to protect themselves by reinventing the wheel every time.

This will come to an end though because in the enterprise space, a number of teams at Microsoft are duplicating features in a number of products, and there will be a crash at some point.</description>
		<content:encoded><![CDATA[<p>&#8220;What I mean by OOXML being half smaller is this: if we had access to the full specs of the binary file formats, then the claim that OOXML has to represent past layouts and behaviours&#8221;</p>
<p>I understand what you mean now. But if Microsoft had to document every single detail of implementation of the binary format, the only way they would be able to do that would be to open up the source code. Indeed, the binary format specs that have been provided in the past are bare references (just like OOXML, bits are described with short sentences, and so on).</p>
<p>I think it&#8217;s fair to say that OOXML is not compelling as a standard since it&#8217;s just the binary formats with angle brackets. (to be honest they&#8217;ve added a few things, but nothing substantial : even their so-called &#8220;great&#8221; custom XML schemas were available in Word 2003 already).</p>
<p>I think that all the noise they made with their new user interface (Ribbon) was a PR scam to try to make IT people think that Office 2007 is really something new and worth upgrading it, even though that was just a change on the surface. That&#8217;s things like this that should be rebutted. But the Microsoft bulldozer is very powerful : no matter how right we are, they have the money to communicate much more effectively to their target customers (through PR wire).</p>
<p>As for OOXML versus ODF, I think it&#8217;s indeed the case that OOXML as we know it does not help the workplace and should be dismissed. We know that Microsoft chose not to work with the OASIS TC just because it was not their stuff, and being the paranoid freaks that they are, they try to protect themselves by reinventing the wheel every time.</p>
<p>This will come to an end though because in the enterprise space, a number of teams at Microsoft are duplicating features in a number of products, and there will be a crash at some point.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Charles</title>
		<link>http://standardsandfreedom.net/index.php/2008/01/19/the-ooxml-bunch-is-boringly-disappointing/comment-page-1/#comment-570</link>
		<dc:creator>Charles</dc:creator>
		<pubDate>Sun, 20 Jan 2008 12:17:01 +0000</pubDate>
		<guid isPermaLink="false">http://standardsandfreedom.net/index.php/2008/01/19/the-ooxml-bunch-is-boringly-disappointing/#comment-570</guid>
		<description>Stephane,

What I mean by OOXML being half smaller is this: if we had access to the full specs of the binary file formats, then the claim that OOXML has to represent past layouts and behaviours would be far less compelling and as such, OOXML itself would not integrate these &quot;features&quot;, partially or fully. Hence the OOXML spec, if it were to even exit in that wonderland, would be far smaller as it would only care about the present or perhaps the future.  

In a more cunning way, one could point out that OOXML would then be useless compared to ODF...

Thank you for your input on Gnumeric!</description>
		<content:encoded><![CDATA[<p>Stephane,</p>
<p>What I mean by OOXML being half smaller is this: if we had access to the full specs of the binary file formats, then the claim that OOXML has to represent past layouts and behaviours would be far less compelling and as such, OOXML itself would not integrate these &#8220;features&#8221;, partially or fully. Hence the OOXML spec, if it were to even exit in that wonderland, would be far smaller as it would only care about the present or perhaps the future.  </p>
<p>In a more cunning way, one could point out that OOXML would then be useless compared to ODF&#8230;</p>
<p>Thank you for your input on Gnumeric!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephane Rodriguez</title>
		<link>http://standardsandfreedom.net/index.php/2008/01/19/the-ooxml-bunch-is-boringly-disappointing/comment-page-1/#comment-569</link>
		<dc:creator>Stephane Rodriguez</dc:creator>
		<pubDate>Sun, 20 Jan 2008 08:19:47 +0000</pubDate>
		<guid isPermaLink="false">http://standardsandfreedom.net/index.php/2008/01/19/the-ooxml-bunch-is-boringly-disappointing/#comment-569</guid>
		<description>A couple of points, 

&quot;If Microsoft were truly delivering the whole specs, not only would the OOXML spec be at least half smaller, (why do you need all these mysteries about faithfully representing past application behaviors?),&quot;

I&#039;m not entirely sure what you mean. To me, if ECMA 376 included all what an implementor needs to support the file formats (create files, migrate, render, ...), I think we are talking something in the range of 600,000 pages.
The fact that ECMA 376 is only 6000 pages proves immediately to me that Microsoft is just throwing a bone to us. They expect that this will be reviewed by people who for the most part have not really a lot of stake in it (i.e. they are no implementors).

&quot;only 3 genuine OOXML implementations&quot;

I don&#039;t think that&#039;s true. Gnumeric is genuine. On the other hand, the fact that Gnumeric has to map XML into its own memory data structure (designed to be compatible with the binary Excel, since Gnumeric is a ten year old project) is an example of failure of the XML-based file format itself. What I mean by that is that if the format was well designed, to maximize the virtues of XML (and therefore interoperability), then Gnumeric would simply load the file into a DOM, and apply all regular XML tooling (XSLT, Xpath, Xquery and so on). It&#039;s not what Gnumeric does at all. It can be easily proven since the source code is available. That&#039;s why OOXML is a failure, it does not advance the state of the art in office document models. That is to me a reason to reject it at ISO, until Microsoft comes up with something far better.

As for the Burton Group study, I have read the rebuttal by the ODF alliance and I have to say I am quite surprised between what the Burton Group arguments are, and what Microsoft own arguments are (particularly through the visibility of their bloggers : Doug Mahugh, and others). I mean by that, the arguments are exactly the same. It is very odd if this was a real study to come up with in fact not just the same arguments but even the same company names supposed to demonstrate how good OOXML is. The particularly ironic one is Mindjet, especially when you know that Doug Mahugh hired the Mindjet CTO last year to become a Microsoft evangelist (the post is here : http://blogs.msdn.com/dmahugh/archive/2007/06/22/san-francisco-workshop.aspx).</description>
		<content:encoded><![CDATA[<p>A couple of points, </p>
<p>&#8220;If Microsoft were truly delivering the whole specs, not only would the OOXML spec be at least half smaller, (why do you need all these mysteries about faithfully representing past application behaviors?),&#8221;</p>
<p>I&#8217;m not entirely sure what you mean. To me, if ECMA 376 included all what an implementor needs to support the file formats (create files, migrate, render, &#8230;), I think we are talking something in the range of 600,000 pages.<br />
The fact that ECMA 376 is only 6000 pages proves immediately to me that Microsoft is just throwing a bone to us. They expect that this will be reviewed by people who for the most part have not really a lot of stake in it (i.e. they are no implementors).</p>
<p>&#8220;only 3 genuine OOXML implementations&#8221;</p>
<p>I don&#8217;t think that&#8217;s true. Gnumeric is genuine. On the other hand, the fact that Gnumeric has to map XML into its own memory data structure (designed to be compatible with the binary Excel, since Gnumeric is a ten year old project) is an example of failure of the XML-based file format itself. What I mean by that is that if the format was well designed, to maximize the virtues of XML (and therefore interoperability), then Gnumeric would simply load the file into a DOM, and apply all regular XML tooling (XSLT, Xpath, Xquery and so on). It&#8217;s not what Gnumeric does at all. It can be easily proven since the source code is available. That&#8217;s why OOXML is a failure, it does not advance the state of the art in office document models. That is to me a reason to reject it at ISO, until Microsoft comes up with something far better.</p>
<p>As for the Burton Group study, I have read the rebuttal by the ODF alliance and I have to say I am quite surprised between what the Burton Group arguments are, and what Microsoft own arguments are (particularly through the visibility of their bloggers : Doug Mahugh, and others). I mean by that, the arguments are exactly the same. It is very odd if this was a real study to come up with in fact not just the same arguments but even the same company names supposed to demonstrate how good OOXML is. The particularly ironic one is Mindjet, especially when you know that Doug Mahugh hired the Mindjet CTO last year to become a Microsoft evangelist (the post is here : <a href="http://blogs.msdn.com/dmahugh/archive/2007/06/22/san-francisco-workshop.aspx)" rel="nofollow">http://blogs.msdn.com/dmahugh/archive/2007/06/22/san-francisco-workshop.aspx)</a>.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.332 seconds -->
