<?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: My comments on the ETRM 4.0 draft</title>
	<atom:link href="http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html/feed" rel="self" type="application/rss+xml" />
	<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=my-comments-on-etrm-40-draft</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: Rob</title>
		<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html#comment-967</link>
		<dc:creator>Rob</dc:creator>
		<pubDate>Thu, 02 Aug 2007 18:28:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2007/07/my-comments-on-the-etrm-4-0-draft.html#comment-967</guid>
		<description>Hi Wraith,&lt;br/&gt;&lt;br/&gt;I don&#039;t think it odd that someone would pick the latest standardized version of ODF.  Why do you think it odd?&lt;br/&gt;&lt;br/&gt;As for &#039;complete implementations&#039; of a standard, consider that there are two things that may cause a vendor to implement a subset: 1) a full implementation is not needed by their customers, or 2) the standard does not specify the features in enough detail to allow a complete implementation. I hope you appreciate that the difference between these two is important.  In the one case, a vendor choses to implement only a portion of the standard, while in the other case a vendor is unable to implement it fully, even if he wanted to,&lt;br/&gt;&lt;br/&gt;My criticism of OOXML is that it cannot be fully implemented because that standard is incomplete, inconsistent and incorrect.  &lt;br/&gt;&lt;br/&gt;Also, note that ITD is not a legislative branch.  These are unelected professionals working for the executive branch, a part of Massachusetts government that recently changed political parties when a new governor was elected.</description>
		<content:encoded><![CDATA[<p>Hi Wraith,</p>
<p>I don&#8217;t think it odd that someone would pick the latest standardized version of ODF.  Why do you think it odd?</p>
<p>As for &#8216;complete implementations&#8217; of a standard, consider that there are two things that may cause a vendor to implement a subset: 1) a full implementation is not needed by their customers, or 2) the standard does not specify the features in enough detail to allow a complete implementation. I hope you appreciate that the difference between these two is important.  In the one case, a vendor choses to implement only a portion of the standard, while in the other case a vendor is unable to implement it fully, even if he wanted to,</p>
<p>My criticism of OOXML is that it cannot be fully implemented because that standard is incomplete, inconsistent and incorrect.  </p>
<p>Also, note that ITD is not a legislative branch.  These are unelected professionals working for the executive branch, a part of Massachusetts government that recently changed political parties when a new governor was elected.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: The Wraith</title>
		<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html#comment-966</link>
		<dc:creator>The Wraith</dc:creator>
		<pubDate>Thu, 02 Aug 2007 18:19:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2007/07/my-comments-on-the-etrm-4-0-draft.html#comment-966</guid>
		<description>Funny enough Massachusets has not adopted the ISO ODF standard but the &#039;interim&#039; v1.1 OASIS version.&lt;br/&gt;&lt;br/&gt;Also we are now already waiting for two years for an important upgrade to ODF in the form of formula&#039;s and also still have to wait for a full implementation of the currents specs.&lt;br/&gt;&lt;br/&gt;Rob himself claimed here on this blog that because of it&#039;s smaller size and reuse of existing standards ODF would be easier to implement than OOXML. But so far this limited size has not led to full implementations and with v1.2 mayby coming this year (??) it is unlikely that we will see any full implementations in 2008 or even in 2009. &lt;br/&gt;&lt;br/&gt;It is very strange for a legislative body to set a standard with two formats that have not proven themselves in real life. Why not just set a requirement on Office document being stored in XML ?</description>
		<content:encoded><![CDATA[<p>Funny enough Massachusets has not adopted the ISO ODF standard but the &#8216;interim&#8217; v1.1 OASIS version.</p>
<p>Also we are now already waiting for two years for an important upgrade to ODF in the form of formula&#8217;s and also still have to wait for a full implementation of the currents specs.</p>
<p>Rob himself claimed here on this blog that because of it&#8217;s smaller size and reuse of existing standards ODF would be easier to implement than OOXML. But so far this limited size has not led to full implementations and with v1.2 mayby coming this year (??) it is unlikely that we will see any full implementations in 2008 or even in 2009. </p>
<p>It is very strange for a legislative body to set a standard with two formats that have not proven themselves in real life. Why not just set a requirement on Office document being stored in XML ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html#comment-964</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Wed, 01 Aug 2007 14:08:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2007/07/my-comments-on-the-etrm-4-0-draft.html#comment-964</guid>
		<description>&gt; cash-strapped and short-staffed (i.e. open source) outfits&lt;br/&gt;&lt;br/&gt;This is not necessarily the case. While many open source projects are in fact staffed by only a few individuals, many of the more successful ones are in fact capable of matching or exceeding the perhaps large, but definitely limited, resources of comparable closed-source efforts. &quot;Open source&quot; does not necessarily imply that everyone is working in their spare time for free. There are numerous examples of long-lived fre and open source projects which have received considerable contribution from commercial vendors who see a business advantage in improving them by collaboration instead of doing everything from scratch on their own. One such example is gcc, and many others surely exist. I am not an expert on this, but I doubt gcc is the only free and open source project to have received such attention.</description>
		<content:encoded><![CDATA[<p>> cash-strapped and short-staffed (i.e. open source) outfits</p>
<p>This is not necessarily the case. While many open source projects are in fact staffed by only a few individuals, many of the more successful ones are in fact capable of matching or exceeding the perhaps large, but definitely limited, resources of comparable closed-source efforts. &#8220;Open source&#8221; does not necessarily imply that everyone is working in their spare time for free. There are numerous examples of long-lived fre and open source projects which have received considerable contribution from commercial vendors who see a business advantage in improving them by collaboration instead of doing everything from scratch on their own. One such example is gcc, and many others surely exist. I am not an expert on this, but I doubt gcc is the only free and open source project to have received such attention.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Queen Elizabeth</title>
		<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html#comment-956</link>
		<dc:creator>Queen Elizabeth</dc:creator>
		<pubDate>Tue, 31 Jul 2007 15:47:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2007/07/my-comments-on-the-etrm-4-0-draft.html#comment-956</guid>
		<description>Stephen: Your statement, &quot;And I can&#039;t begin to tell you how many problems I&#039;ve had transferring files between MS Office for Mac to Office for Windows&quot; is a case-in-point of what I mean.&lt;br/&gt;&lt;br/&gt;Mac Office is actually a different implementation with a different codebase than Windows Office.&lt;br/&gt;&lt;br/&gt;If one company with enormous resources can&#039;t even guarantee interoperability across the same format in its own implementations, what are the odds that multiple, often cash-strapped and short-staffed (i.e. open source) outfits can do better?&lt;br/&gt;&lt;br/&gt;Or think about it this way:&lt;br/&gt;- SVG became a standard in 2001.&lt;br/&gt;- ODF became a standard in 2006.&lt;br/&gt;- SVG is a part of ODF.&lt;br/&gt;- AFAIK nobody has yet produced a complete implementation of SVG.&lt;br/&gt;&lt;br/&gt;Six years have passed at yet SVG is still very poorly supported. This does not bode well for ODF. If developers can&#039;t implement the part, how in the world are they going to do the whole?</description>
		<content:encoded><![CDATA[<p>Stephen: Your statement, &#8220;And I can&#8217;t begin to tell you how many problems I&#8217;ve had transferring files between MS Office for Mac to Office for Windows&#8221; is a case-in-point of what I mean.</p>
<p>Mac Office is actually a different implementation with a different codebase than Windows Office.</p>
<p>If one company with enormous resources can&#8217;t even guarantee interoperability across the same format in its own implementations, what are the odds that multiple, often cash-strapped and short-staffed (i.e. open source) outfits can do better?</p>
<p>Or think about it this way:<br />- SVG became a standard in 2001.<br />- ODF became a standard in 2006.<br />- SVG is a part of ODF.<br />- AFAIK nobody has yet produced a complete implementation of SVG.</p>
<p>Six years have passed at yet SVG is still very poorly supported. This does not bode well for ODF. If developers can&#8217;t implement the part, how in the world are they going to do the whole?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bruce</title>
		<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html#comment-954</link>
		<dc:creator>Bruce</dc:creator>
		<pubDate>Tue, 31 Jul 2007 02:24:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2007/07/my-comments-on-the-etrm-4-0-draft.html#comment-954</guid>
		<description>Luc: as a now-independent member of the TC, I also don&#039;t see the conspiracy Sam et al are (in my view quite carelessly) claiming. It&#039;s a simple and convenient argument, but I just don&#039;t think it&#039;s supported by any facts.</description>
		<content:encoded><![CDATA[<p>Luc: as a now-independent member of the TC, I also don&#8217;t see the conspiracy Sam et al are (in my view quite carelessly) claiming. It&#8217;s a simple and convenient argument, but I just don&#8217;t think it&#8217;s supported by any facts.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob</title>
		<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html#comment-953</link>
		<dc:creator>Rob</dc:creator>
		<pubDate>Mon, 30 Jul 2007 21:26:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2007/07/my-comments-on-the-etrm-4-0-draft.html#comment-953</guid>
		<description>Hi Luc,&lt;br/&gt;&lt;br/&gt;I think you are referring to the OpenDocument Foundation, not to be confused with the ODF Alliance or the OpenDocument Fellowship, or for that matter, the Oregon Department of Forestry.   The Foundation is a small but vocal nonprofit, run by Gary Edwards and friends. The ODF Alliance, on the other hand, has over 300 members, including IBM and Sun.&lt;br/&gt;&lt;br/&gt;I guess I&#039;d ask the Foundation, what level of interoperability would you expect between ODF 1.0 and OOXML 1.0, considering that ODF was designed, created, reviewed, edited and standardized years before standards work even started on OOXML?  I think it is odd to suggest that ODF (and Sun) are solely responsible for interoperability with something that came out later.  &lt;br/&gt;&lt;br/&gt;I&#039;d also ask, if Sun is trying to prevent interoperability with Office, then why did Sun write an Office Plugin for ODF?  That doesn&#039;t sound like something you do if you are trying to prevent interoperability with Office, does it?&lt;br/&gt;&lt;br/&gt;I have as much tinfoil in my hat as the next guy, but I just don&#039;t see this conspiracy.</description>
		<content:encoded><![CDATA[<p>Hi Luc,</p>
<p>I think you are referring to the OpenDocument Foundation, not to be confused with the ODF Alliance or the OpenDocument Fellowship, or for that matter, the Oregon Department of Forestry.   The Foundation is a small but vocal nonprofit, run by Gary Edwards and friends. The ODF Alliance, on the other hand, has over 300 members, including IBM and Sun.</p>
<p>I guess I&#8217;d ask the Foundation, what level of interoperability would you expect between ODF 1.0 and OOXML 1.0, considering that ODF was designed, created, reviewed, edited and standardized years before standards work even started on OOXML?  I think it is odd to suggest that ODF (and Sun) are solely responsible for interoperability with something that came out later.  </p>
<p>I&#8217;d also ask, if Sun is trying to prevent interoperability with Office, then why did Sun write an Office Plugin for ODF?  That doesn&#8217;t sound like something you do if you are trying to prevent interoperability with Office, does it?</p>
<p>I have as much tinfoil in my hat as the next guy, but I just don&#8217;t see this conspiracy.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Luc Bollen</title>
		<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html#comment-952</link>
		<dc:creator>Luc Bollen</dc:creator>
		<pubDate>Mon, 30 Jul 2007 21:23:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2007/07/my-comments-on-the-etrm-4-0-draft.html#comment-952</guid>
		<description>Oops...  Of course, I should have written &quot;OpenDocument Foundation&quot;, not &quot;ODF Alliance&quot;.  Sorry for this.</description>
		<content:encoded><![CDATA[<p>Oops&#8230;  Of course, I should have written &#8220;OpenDocument Foundation&#8221;, not &#8220;ODF Alliance&#8221;.  Sorry for this.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Luc Bollen</title>
		<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html#comment-951</link>
		<dc:creator>Luc Bollen</dc:creator>
		<pubDate>Mon, 30 Jul 2007 20:52:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2007/07/my-comments-on-the-etrm-4-0-draft.html#comment-951</guid>
		<description>Rob,&lt;br/&gt;&lt;br/&gt;The ODF Alliance is claiming that inter-operability between ODF and OOXML remains low because Sun is blocking the evolution of ODF.&lt;br/&gt;&lt;br/&gt;I consider this a very serious issue, as the current difficulty to translate between the 2 formats results in ground being lost everyday by ODF.&lt;br/&gt;&lt;br/&gt;Could you please let us know you view, and IBM&#039;s view, on this issue ?  Thanks.</description>
		<content:encoded><![CDATA[<p>Rob,</p>
<p>The ODF Alliance is claiming that inter-operability between ODF and OOXML remains low because Sun is blocking the evolution of ODF.</p>
<p>I consider this a very serious issue, as the current difficulty to translate between the 2 formats results in ground being lost everyday by ODF.</p>
<p>Could you please let us know you view, and IBM&#8217;s view, on this issue ?  Thanks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sam</title>
		<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html#comment-949</link>
		<dc:creator>Sam</dc:creator>
		<pubDate>Mon, 30 Jul 2007 17:07:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2007/07/my-comments-on-the-etrm-4-0-draft.html#comment-949</guid>
		<description>I concur with Rob&#039;s point down here, except to add that a UNIVERSALLY INTEROPERABLE version of ODF is even more preferable.&lt;br/&gt;&lt;br/&gt;By this I mean an ODF or ODEF that is designed to handle differences in file contents which arise from implementation differences. I believe this can be done with a strong enough design &amp; consortium which is not conflicted by business relationships of marketing office suite software implementations.&lt;br/&gt;&lt;br/&gt;A successful ODF/ODEF is truly vendor-neutral. The trouble we are having is that the vendors are defining the standard and they are all doing an inadequate job because the profit motive interferes with the public interest in having a genuine universally interoperable document format.</description>
		<content:encoded><![CDATA[<p>I concur with Rob&#8217;s point down here, except to add that a UNIVERSALLY INTEROPERABLE version of ODF is even more preferable.</p>
<p>By this I mean an ODF or ODEF that is designed to handle differences in file contents which arise from implementation differences. I believe this can be done with a strong enough design &#038; consortium which is not conflicted by business relationships of marketing office suite software implementations.</p>
<p>A successful ODF/ODEF is truly vendor-neutral. The trouble we are having is that the vendors are defining the standard and they are all doing an inadequate job because the profit motive interferes with the public interest in having a genuine universally interoperable document format.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steven G. Johnson</title>
		<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html#comment-945</link>
		<dc:creator>Steven G. Johnson</dc:creator>
		<pubDate>Sun, 29 Jul 2007 23:02:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2007/07/my-comments-on-the-etrm-4-0-draft.html#comment-945</guid>
		<description>It&#039;s true that if you have a single format and a single implementation then, almost by definition, you have no compatibility problems.  There&#039;s nothing to be compatible &lt;i&gt;with&lt;/i&gt;.&lt;br/&gt;&lt;br/&gt;That is, as long as you have that implementation; if you use a different operating system, or an operating system 20 years from now that doesn&#039;t run that &quot;single&quot; implementation, you are out of luck.  And in any case, we don&#039;t have a &quot;single&quot; implementation even now, because MS keeps updating Office and changing the file format.  And I can&#039;t begin to tell you how many problems I&#039;ve had transferring files between MS Office for Mac to Office for Windows.&lt;br/&gt;&lt;br/&gt;Moreover, Massachusetts (and others) have already decided that being locked into a &quot;single&quot; implementation by a single vendor is unacceptable for public documents.  This debate is already over: it has already been decided that multiple implementations is desirable, so the only decision is whether to have multiple implementations of multiple open standards or multiple implementations of one open standard.&lt;br/&gt;&lt;br/&gt;...At least, to the extent that you consider OOXML to be fully &quot;open&quot; or fully implementable by multiple vendors.</description>
		<content:encoded><![CDATA[<p>It&#8217;s true that if you have a single format and a single implementation then, almost by definition, you have no compatibility problems.  There&#8217;s nothing to be compatible <i>with</i>.</p>
<p>That is, as long as you have that implementation; if you use a different operating system, or an operating system 20 years from now that doesn&#8217;t run that &#8220;single&#8221; implementation, you are out of luck.  And in any case, we don&#8217;t have a &#8220;single&#8221; implementation even now, because MS keeps updating Office and changing the file format.  And I can&#8217;t begin to tell you how many problems I&#8217;ve had transferring files between MS Office for Mac to Office for Windows.</p>
<p>Moreover, Massachusetts (and others) have already decided that being locked into a &#8220;single&#8221; implementation by a single vendor is unacceptable for public documents.  This debate is already over: it has already been decided that multiple implementations is desirable, so the only decision is whether to have multiple implementations of multiple open standards or multiple implementations of one open standard.</p>
<p>&#8230;At least, to the extent that you consider OOXML to be fully &#8220;open&#8221; or fully implementable by multiple vendors.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob</title>
		<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html#comment-944</link>
		<dc:creator>Rob</dc:creator>
		<pubDate>Sun, 29 Jul 2007 22:52:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2007/07/my-comments-on-the-etrm-4-0-draft.html#comment-944</guid>
		<description>Certainly, there are two dimensions to the question: the format and the application.  The ETRM, as a reference architecture, is specifying the formats, not the applications.  The choice of applications is a separate one. &lt;br/&gt;&lt;br/&gt;Glitches certainly will occur with multiple applications, and vendors will fix them.  It is a well-known engineering problem with well-known solutions.  Look at network protocols, TCP/IP, SMTP, POP3, etc.    Not many glitches today.  &lt;br/&gt;&lt;br/&gt;But certainly having multiple applications with multiple formats will have more glitches than having  multiple applications with a single format, right?  I&#039;m aware of no argument that suggests that having more formats improves interoperability.  If that were indeed true, then why not have 3, 4 or 5 formats?  Heck, if having more formats improves interoperability, then let&#039;s have a hundred!&lt;br/&gt;&lt;br/&gt;I agree with you that interoperability is maximized with a single format and a single application.  But it is better to have a choice of applications and then to chose one, rather than to have no choice and be stuck with a single application by default.  That way you can simultaneously maximize interoperability within the department, as well as maximize some other desirable, such as features, cost, support, ease of use, etc.&lt;br/&gt;&lt;br/&gt;Your example of web browsers is an interesting one.  The problem there wasn&#039;t really the complexity of the standards, but the unwillingness of Microsoft to follow web standards.      With a monopoly you can kill most standards by mere neglect.  Luckily Firefox came along and brought a little competition to the market.  Improved web standards support in  Internet Explorer soon followed.</description>
		<content:encoded><![CDATA[<p>Certainly, there are two dimensions to the question: the format and the application.  The ETRM, as a reference architecture, is specifying the formats, not the applications.  The choice of applications is a separate one. </p>
<p>Glitches certainly will occur with multiple applications, and vendors will fix them.  It is a well-known engineering problem with well-known solutions.  Look at network protocols, TCP/IP, SMTP, POP3, etc.    Not many glitches today.  </p>
<p>But certainly having multiple applications with multiple formats will have more glitches than having  multiple applications with a single format, right?  I&#8217;m aware of no argument that suggests that having more formats improves interoperability.  If that were indeed true, then why not have 3, 4 or 5 formats?  Heck, if having more formats improves interoperability, then let&#8217;s have a hundred!</p>
<p>I agree with you that interoperability is maximized with a single format and a single application.  But it is better to have a choice of applications and then to chose one, rather than to have no choice and be stuck with a single application by default.  That way you can simultaneously maximize interoperability within the department, as well as maximize some other desirable, such as features, cost, support, ease of use, etc.</p>
<p>Your example of web browsers is an interesting one.  The problem there wasn&#8217;t really the complexity of the standards, but the unwillingness of Microsoft to follow web standards.      With a monopoly you can kill most standards by mere neglect.  Luckily Firefox came along and brought a little competition to the market.  Improved web standards support in  Internet Explorer soon followed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Queen Elizabeth</title>
		<link>http://www.robweir.com/blog/2007/07/my-comments-on-etrm-40-draft.html#comment-943</link>
		<dc:creator>Queen Elizabeth</dc:creator>
		<pubDate>Sun, 29 Jul 2007 22:24:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.robweir.com/blog/2007/07/my-comments-on-the-etrm-4-0-draft.html#comment-943</guid>
		<description>Claiming that ODF will prevent a slide back into &quot;the confusion and frustration of the early 1990’s when we all juggled WordStar, WordPerfect, Word and WordPro files, and could collaborate only poorly&quot; is a tad disingenuous.&lt;br/&gt;&lt;br/&gt;The reason why document exchange problems fell by the wayside is because Office displaced all of its competitors. We did not only have one standard; we had one implementation. Hence [almost] no compatibility problems!&lt;br/&gt;&lt;br/&gt;What happens if ODF succeeds in loosening the Office juggernaut? We will move from one format + one implementation to one format + many implementations.&lt;br/&gt;&lt;br/&gt;Such proliferation will *inevitably* lead to hitches and glitches in document exchange. (Even today, no browser fully supports the open standards XHTML/CSS.) Given how much more complex ODF is--and the fact that no implementation supports it fully and with few bugs--document exchange problems will *increase* if it becomes the standard.&lt;br/&gt;&lt;br/&gt;I&#039;m not saying ODF is bad, or that monopolies are good, but spreading ODF could take us back to the very bad days not only of &quot;WordStar, WordPerfect, Word and WordPro&quot; but also Mosaic, Netscape, and Internet Explorer.</description>
		<content:encoded><![CDATA[<p>Claiming that ODF will prevent a slide back into &#8220;the confusion and frustration of the early 1990’s when we all juggled WordStar, WordPerfect, Word and WordPro files, and could collaborate only poorly&#8221; is a tad disingenuous.</p>
<p>The reason why document exchange problems fell by the wayside is because Office displaced all of its competitors. We did not only have one standard; we had one implementation. Hence [almost] no compatibility problems!</p>
<p>What happens if ODF succeeds in loosening the Office juggernaut? We will move from one format + one implementation to one format + many implementations.</p>
<p>Such proliferation will *inevitably* lead to hitches and glitches in document exchange. (Even today, no browser fully supports the open standards XHTML/CSS.) Given how much more complex ODF is&#8211;and the fact that no implementation supports it fully and with few bugs&#8211;document exchange problems will *increase* if it becomes the standard.</p>
<p>I&#8217;m not saying ODF is bad, or that monopolies are good, but spreading ODF could take us back to the very bad days not only of &#8220;WordStar, WordPerfect, Word and WordPro&#8221; but also Mosaic, Netscape, and Internet Explorer.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

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

