<?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/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"
	>
<channel>
	<title>Comments on: Why is OOXML Slow?</title>
	<atom:link href="http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=why-is-ooxml-slow</link>
	<description>Thinking the unthinkable, pondering the imponderable, effing the ineffable and scruting the inscrutable</description>
	<lastBuildDate>Tue, 07 Feb 2012 11:20:47 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Anonymous</title>
		<link>http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html#comment-511</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Thu, 15 Feb 2007 17:45:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html#comment-511</guid>
		<description>Any chance you can post plots of those charts with the ratios reversed? (This verifies that the ratio isn&#039;t biasing the plotting).  The real problem with OOXML is that MS XML experts applied a new paradigm to the old way of doing things.  The new XML paradigm should be coupled with a review of the way the customer does things and how he could improve the way things are done.  MS Office has been the business office software standard for quite some time now and MS thinks it knows more about its customers needs than its customers do.  MS needed to team with its customers not develop OOXML in an ivory tower in Redmond.</description>
		<content:encoded><![CDATA[<p>Any chance you can post plots of those charts with the ratios reversed? (This verifies that the ratio isn&#8217;t biasing the plotting).  The real problem with OOXML is that MS XML experts applied a new paradigm to the old way of doing things.  The new XML paradigm should be coupled with a review of the way the customer does things and how he could improve the way things are done.  MS Office has been the business office software standard for quite some time now and MS thinks it knows more about its customers needs than its customers do.  MS needed to team with its customers not develop OOXML in an ivory tower in Redmond.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob</title>
		<link>http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html#comment-141</link>
		<dc:creator>Rob</dc:creator>
		<pubDate>Sat, 21 Oct 2006 15:36:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html#comment-141</guid>
		<description>hAl,&lt;br/&gt;&lt;br/&gt;I&#039;ve certainly checked these documents to ensure that the conversions were successful.  There is no evident data loss.  The source documents were simple, generally plain text with little styling, some embedded graphics, but nothing complicated.  OpenOffice does a great job at converting documents like these.&lt;br/&gt;&lt;br/&gt;Of course, I say there are no &quot;evident&quot; differences.  Who knows what differences there are that are not visible?  Of course, that is true even if I took your approach of creating the documents from scratch in both word processors.  How do I know that both are saving the same amount of information?  &lt;br/&gt;&lt;br/&gt;For example, whether I want it or not, Office 2007 tracks revision ID&#039;s for every block of text I enter into a document.  This is in the rsidR attribute in document.xml, also referenced in settings.xml.  This is tracked even though I do not have &quot;Track Changes&quot; enabled in Word. This can take up a considerable amount of space.  OpenOffice does not do anything like this.  So even if I created documents from scratch in both word processors, OOXML would come out at a disadvantage because of that.&lt;br/&gt;&lt;br/&gt;Another approach would be to hand-craft these XML files in an XML editor based purely on the specifications.  This would be very time consuming, and even then I could still be accused on not taking advantage of the optimal encoding of the document allowed by each document.&lt;br/&gt;&lt;br/&gt;However, as Microsoft has said on numerous occasions, the legacy support of the &quot;billions&quot; of outstanding Office documents is great importance.  I believe this test accurately reflects the performance characteristics that these legacy documents will see when converted to OpenOffice or Office 2007.  This is a real-world use and should be a real-world concern.</description>
		<content:encoded><![CDATA[<p>hAl,</p>
<p>I&#8217;ve certainly checked these documents to ensure that the conversions were successful.  There is no evident data loss.  The source documents were simple, generally plain text with little styling, some embedded graphics, but nothing complicated.  OpenOffice does a great job at converting documents like these.</p>
<p>Of course, I say there are no &#8220;evident&#8221; differences.  Who knows what differences there are that are not visible?  Of course, that is true even if I took your approach of creating the documents from scratch in both word processors.  How do I know that both are saving the same amount of information?  </p>
<p>For example, whether I want it or not, Office 2007 tracks revision ID&#8217;s for every block of text I enter into a document.  This is in the rsidR attribute in document.xml, also referenced in settings.xml.  This is tracked even though I do not have &#8220;Track Changes&#8221; enabled in Word. This can take up a considerable amount of space.  OpenOffice does not do anything like this.  So even if I created documents from scratch in both word processors, OOXML would come out at a disadvantage because of that.</p>
<p>Another approach would be to hand-craft these XML files in an XML editor based purely on the specifications.  This would be very time consuming, and even then I could still be accused on not taking advantage of the optimal encoding of the document allowed by each document.</p>
<p>However, as Microsoft has said on numerous occasions, the legacy support of the &#8220;billions&#8221; of outstanding Office documents is great importance.  I believe this test accurately reflects the performance characteristics that these legacy documents will see when converted to OpenOffice or Office 2007.  This is a real-world use and should be a real-world concern.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: hAl</title>
		<link>http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html#comment-138</link>
		<dc:creator>hAl</dc:creator>
		<pubDate>Fri, 20 Oct 2006 12:02:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html#comment-138</guid>
		<description>Another weird test. &lt;br/&gt;How can you test with .doc files that are converted to ODF. &lt;br/&gt;I told Jeff Reliife as well that that isn&#039;t a good start of his test. You cannot be sure that what you are testing is actually the same thing. The converted files in ODF might be a lot more basic than the OOXML files.&lt;br/&gt;&lt;br/&gt;For those that really want to test they will have to create some files and not convert them from some another format !!!&lt;br/&gt;Converting to another format often leads to simpler files with less functionality. &lt;br/&gt;This is even already the case if you convert ODF files to ODF files using another application.&lt;br/&gt;&lt;br/&gt;Very poor rating for this test. But keep going you guys at IBM. It looks you got quite a few people on it at moment.</description>
		<content:encoded><![CDATA[<p>Another weird test. <br />How can you test with .doc files that are converted to ODF. <br />I told Jeff Reliife as well that that isn&#8217;t a good start of his test. You cannot be sure that what you are testing is actually the same thing. The converted files in ODF might be a lot more basic than the OOXML files.</p>
<p>For those that really want to test they will have to create some files and not convert them from some another format !!!<br />Converting to another format often leads to simpler files with less functionality. <br />This is even already the case if you convert ODF files to ODF files using another application.</p>
<p>Very poor rating for this test. But keep going you guys at IBM. It looks you got quite a few people on it at moment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob</title>
		<link>http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html#comment-136</link>
		<dc:creator>Rob</dc:creator>
		<pubDate>Fri, 20 Oct 2006 02:21:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html#comment-136</guid>
		<description>Thanks.  I wouldn&#039;t want to be on the other side of this argument either ;-)</description>
		<content:encoded><![CDATA[<p>Thanks.  I wouldn&#8217;t want to be on the other side of this argument either ;-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ben Langhinrichs</title>
		<link>http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html#comment-135</link>
		<dc:creator>Ben Langhinrichs</dc:creator>
		<pubDate>Fri, 20 Oct 2006 00:41:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2006/10/why-is-ooxml-slow.html#comment-135</guid>
		<description>I would really, really not want you on the opposite team in a debate (and, yes, that is a compliment).</description>
		<content:encoded><![CDATA[<p>I would really, really not want you on the opposite team in a debate (and, yes, that is a compliment).</p>
]]></content:encoded>
	</item>
</channel>
</rss>

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

