“The OpenDocument Format is an emerging file format standard for electronic office documents. Representing a triumph of common sense over the methods conceived before the rise of the Internet, ODF’s goals are both exciting and controversial. Early adopters of the format include state and municipal governments in some near and far-flung places, and this makes the format’s progress a thing to watch. Yet innovation theory tells us there are some hurdles we all must overcome before ODF becomes a regular topic of conversation at the ballpark. Those in the know, however, recognize that we’re in about the second inning of a barn-burner. So, grab a hot dog and a beer, and settle in for a classic.”
Seems Microsoft has redefined the words “open,” “competition,” and “accessibility.” I’m glad that at least some government organizations have the ability to see through the sham.
Whatever. OpenXML has been submitted to the ECMA standards body, so it’s truly subject to industry feedback.
I don’t know why we need article like this to explain it. oh yes i do… Shaman said it “Seems Microsoft has redefined the words “open,” “competition,” and “accessibility.”” – unfortunately too many people fall for Microsoft jargon
ODF is encumbered by patents held by Sun.
PDF is encumbered by patents held by Adobe.
Yet because they aren’t Microsoft, OSS redefines ODF and PDF to be “open”.
What a joke.
Edited 2006-08-21 21:23
“ODF is encumbered by patents held by Sun.
PDF is encumbered by patents held by Adobe.
Yet because they aren’t Microsoft, OSS redefines ODF and PDF to be “open””
Actually, they are considered to be open as the specification is open. Anyone can write a program that can read and write these formats by following the open specification of them. There is no patent incumberance doing it that way at all. Microsoft’s file formats are poorly documented making it extremely difficult to wirte a full functioning program that would support their formats properly. That is the difference.
Okay, I get that much in regards to Microsoft’s current Office file formats. But what about Microsoft’s upcoming OpenXML formats? I recall there was still some openness issue that people had with it, but I forget the specific complaints.
Edit: Oh, and doesn’t Adobe prevent alternative pdf writers from being made?
Edited 2006-08-21 21:50
“Okay, I get that much in regards to Microsoft’s current Office file formats. But what about Microsoft’s upcoming OpenXML formats? I recall there was still some openness issue that people had with it, but I forget the specific complaints.
Edit: Oh, and doesn’t Adobe prevent alternative pdf writers from being made? “
I think some of the complaints had to do with the MS OpenXML deviated from the XML standard, and was not fully open, as in the full specs were not published.
Not sure about Adobe on that one to be honest. If that is the case then OpenOffice has issues as they write directly to PDF. I am actually confused on that one as well as they stopped Microsoft from implementing a PDF writer into Word if I remember correctly. Could be wrong though.
*Edit: Corrected typo
Edited 2006-08-21 21:55
PDF can be implemented by anyone. Adobe however does not want MS to include PDF export to MS Office by default.
The reason for this is, that MS would in that way ruin Adobe’s business of selling licenses for their PDF creating software. Adobe does not propose patent or copyright arguments to make MS retract that feature, but antitrust arguments. Adbobe says that the market dominance of MS Office would be an unfair advantage in the PDF creating software market, that MS would use its monopoly in office software to gain another monopoly in the PDF creating market.
So this bantering between Adobe and MS has nothing to do with intellectual property or format open/closedness.
PDF is an open format, because everybody can make software which writes and reads PDF documents. If MS is barred from writing PDF due to antitrust reasons, it is Microsofts problem. They could decide to split themselves into two companies which start off with the same source code. Then none would be a monopoly any more and they would not have to fear the anti-trust regulations anymore.
“The reason for this is, that MS would in that way ruin Adobe’s business of selling licenses for their PDF creating software.”
Thanks for clearing that up, as it did have me kind of confused. It makes sense in a way, however to me it belittles the openness of it, as that is no longer Adobe’s cash cow so to speak as there are many packages out there which allow you to write, read, and edit PDF documents.
If PDF isn’t open for all to use, it’s not truly open at all.
Yes, Adobe wanted to protect its PDF creation biz, which is based on converting MS Office docs to PDF. (Rather than threatening to sue, Adobe could’ve competed by adding features to its PDF software or lowering the price.)
But did you know that Adobe proposed to Microsoft that Adobe would allow built-in PDF export in Office 2007 if Microsoft increased the price of Office 2007 so as to not undercut the price of Adobe’s PDF creation software? In other words, Adobe proposed colluding with MS in price-fixing regarging software that converts MS Office docs to PDF files. Price-fixing is as anti-consumer as you can get. Pleasse stop pretending that Adobe is on the side of the angels. Adobe currently has a monopoly on converting MS Office docs to PDF, and Adobe wants to protect that monopoly, even going as far as proposing collusiion and price-fixing.
//If PDF isn’t open for all to use, it’s not truly open at all. //
I’d have to agree with that thought.
However, I’d also point out that PDF is more open than XPS and certainly far more possible for all to use than Office Open XML is.
Edit: Oh, and doesn’t Adobe prevent alternative pdf writers from being made?
If that is so, it seems very odd that OpenOffice.org has an export to PDF feature.
Okay, I get that much in regards to Microsoft’s current Office file formats. But what about Microsoft’s upcoming OpenXML formats? I recall there was still some openness issue that people had with it, but I forget the specific complaints.
One of the concerns is that Microsoft will make the standard available under a public license that could be incompatible or difficult to integrate with OSS. I don’t think that’s been established one way or the other yet.
Edit: Oh, and doesn’t Adobe prevent alternative pdf writers from being made?
No, it’s a published standard, anyone can implement it. You just can’t change it or modify it to become an incompatible standard, which is what they were worried Microsoft would do.
There are a number of free pdf creator tools available on a number of platforms. Some free apps, such as KWord, can even edit pdf files.
One of the concerns is that Microsoft will make the standard available under a public license that could be incompatible or difficult to integrate with OSS. I don’t think that’s been established one way or the other yet.
No, you’re right. That one currently lives in the FUD category.
//No, you’re right. That one currently lives in the FUD category.//
I don’t believe it is FUD at all. Microsoft appear to have made it “legally” possible to write an Office Open XML compatible application that will target a platform other than Windows, but technically impossible to guarantee that all Office Open XML documents created on Windows platforms will render fully and correctly on other platforms.
Office Open XML is simply not a cross-platform specification and it is not vendor neutral.
I don’t believe it is FUD at all. Microsoft appear …
Hence, FUD.
…to have made it “legally” possible to write an Office Open XML compatible application that will target a platform other than Windows, but technically impossible to guarantee that all Office Open XML documents created on Windows platforms will render fully and correctly on other platforms.
That’s ridiculous. Any application can read the Open XML format and apply the same rendering rules that MS uses.
Office Open XML is simply not a cross-platform specification and it is not vendor neutral.
Thanks for the opinion. But it’s simply false.
//I recall there was still some openness issue that people had with it, but I forget the specific complaints.//
The biggest issue with Microsoft’s Office Open XML format specification is that the specification references other Microsoft-specific functions. The Office Open XML format specification is neither cross-platform nor vendor neutral.
Quote from the article linked to:
The ECMA specification for Office Open XML reveals that Microsoft intends to tie functions within its Office 2007 office suite, functions within its new Vista operating system, and functions within its Exchange Server and SharePoint Portal Server to its new, XML-ready document file format. Continuing to tie the new XML file format not only defeats the design objectives of XML, but clearly perpetuates a familiar control by the company over customers’ document data and software upgrade cycles.
This means that:
(1) One can ONLY write an application that runs on the Windows platform to process Office Open XML format data, and
(2) Microsoft retain for themselves a very significant advantage in the creation of applications to manipulate Office Open XML format because of Microsoft’s intimate knowledge of the other components of Windows platforms upon which the format relies. Those other components are most decidedly not open at all.
Therefore, Office Open XML format is merely yet another lock-in strategy to Microsoft platforms, only this time it is thinly disguised which gives some people an opportunity to claim it as open and deny that it limits competition.
Edited 2006-08-22 01:20
The ECMA specification for Office Open XML reveals that Microsoft intends to tie functions within its Office 2007 office suite…
What does that mean, exactly? How do you “tie function[s]” to an XML format? Since the specification is open via ECMA standards body, how does anything MS does with its Office, Windows, or Sharepoint products have any bearing on the specification — or your ability to use that specification?
//What does that mean, exactly? How do you “tie function[s]” to an XML format? Since the specification is open via ECMA standards body, how does anything MS does with its Office, Windows, or Sharepoint products have any bearing on the specification — or your ability to use that specification?//
It means that according to the Office Open XML specification certain elements can be embedded into documents that rely on Office, Windows, or Sharepoint products in order to be rendered. One can embed calls to ActiveX within a document, for example. There are a multitude of ways to put things into an Office Open XML document (without warning) that will subsequently “tie” that document to being further rendered (displayed) or edited by either the same Windows platform as was used to create it (in the case of DRM provisions), or at the very least another Windows platform with access to all of the same Microsoft products installed as the original platform which created the document.
It means that according to the Office Open XML specification certain elements can be embedded into documents that rely on Office, Windows, or Sharepoint products in order to be rendered. One can embed calls to ActiveX within a document, for example. There are a multitude of ways to put things into an Office Open XML document (without warning) that will subsequently “tie” that document to being further rendered (displayed) or edited by either the same Windows platform …
That’s marginal functionality. The fact of the matter is that that capability exists in Word currently, but the vast number of .DOCs exchanged by users do not contain embedded ActiveX controls or similar kinds of embedded content.
//That’s marginal functionality. The fact of the matter is that that capability exists in Word currently, but the vast number of .DOCs exchanged by users do not contain embedded ActiveX controls or similar kinds of embedded content.//
It is just one example out of a myriad. There is no warning that you are about to use a feature that will irretrievably tie your document to MS Windows platforms. If your company decides to use Office Open XML, it will tie the company inextricably to the Microsoft platform and associated license costs, software audits, license compliance administration overhead and upgrade treadmill.
There is a simple and effective solution to all these woes – don’t use Office Open XML. Use ODF. If Office 12 fully supports ODF then fine, use Office 12 if you like – but don’t save your documents in Office Open XML format, use only the ODF support.
That way you will be guaranteed to future-proof your documents, make it possible for yourself to switch to another platform at a later time if that is what you decide to do, allow you to run a mixed-platform shop if that is what you decide to do, guarantee the ability to exchange documents with other firms that do not run a Windows shop, and be a company that can claim it is compliant to standards.
It is all upside to use ODF. It is all downside to risk using Office Open XML.
It is just one example out of a myriad. There is no warning that you are about to use a feature that will irretrievably tie your document to MS Windows platforms. If your company decides to use Office Open XML, it will tie the company inextricably to the Microsoft platform and associated license costs, software audits, license compliance administration overhead and upgrade treadmill.
Since all of these features exist in .DOC files already, why aren’t people seeing the kinds of interchange problems that you claim to exist? I routinely exchange .DOC files with people and have no such problems. Methinks you’re trying to stir a teacup and produce a tempest.
The big difference between ODF and Office Open XML is that the first is intended to be a common standard while the latter is aimed to replace the old binary formats of the Office.
Even if the Office Open XML isn’t aimed to be the choice for all the other Office-suites, interoperability is still possible and much easier to accomplish, than with the old binary Office-formats (.doc, .xls etc).
Naturally, Office Open XML has to support everything that the old formats do (like OLE-objects etc) and all the new features that are important part of the new Office System 2007. As long as all the features will be in the specs (when they are ready), I don’t see any problem with that.
“Those other components are most decidedly not open at all.”
I haven’t checked how well they are specified or will be. We’ll see it after the specs are out of beta – it is still too early to declare that the other components won’t be specified at all.
Anyway, you don’t have to use all the possible features to be able to read or write compatible Open XML -files.
You can edit Open XML files with a simple text editor or easily by code. And if the document contains those platform-specific features, you can still read and manipulate the normal parts of the documents.
You don’t have to support those Vista, SharePoint etc. specific features (whatever they are) from another office suite to produce fully-featured Office documents that are enough for most people. These platform-specific features are for very marginal needs, anyway. Standard business documents are not that complicated in most cases (some styles, graphics etc).
// Anyway, you don’t have to use all the possible features to be able to read or write compatible Open XML -files.//
If you don’t need to put escoteric Windows dependencies in your documents, why run Office 12 at all and suffer the risk of lock-in to Microsoft products? Why not just use OpenOffice or StarOffice right now?
The portability of legacy MS Office old-format documents into the current OpenOffice or especially StarOffice is likely to be at least as good as the portability to Office 12 anyway.
//You don’t have to support those Vista, SharePoint etc. specific features (whatever they are) from another office suite to produce fully-featured Office documents that are enough for most people. These platform-specific features are for very marginal needs, anyway. Standard business documents are not that complicated in most cases (some styles, graphics etc).//
You miss the point entirely. Zoom. It has gone a zillion miles over your head.
If you opt to use Office 12 and Office Open XML, it is possible to put something into a document you are writing that will mean that anyone who wants to open it (even yourself years form now) will HAVE to be running an application on a Windows platform. You may not even be aware you have locked yourself in until it is way too late.
If at a later time you run a supposedly Office Open XML compatible application on a non-Windows platform, you run a risk of not being able to access all of the features of the original document. If many years later you open the document you create next year with Office 12 using a later version of Office or of Windows (or with anything other than the current set of dependencies), you also run a risk of not having access to all of the features of your own document … let alone anyone else’s document.
You are not in control of your own data, if you use Office Open XML.
Office Open XML is not interoperable with other platforms, by design, and it is not future-proof, by design, and it gives a distinct advantage to Microsoft to write applications for it, by design, and it requires a Windows platform to run on, by design.
Office Open XML is designed to lock you in. It is designed to hold your data hostage, and make you forever beholden to Microsoft to access that data. Let alone the fact that it is also designed so that everyone else who wants to be able to use your data that you may wish to give information to is also beholden to run Microsoft.
If you are a business, do you really want the whims of another company to be a critical single point of failure for your data? Do you really want your digital records to be under the control of another company? If your customers decide that they do not want to run a similar risk, and they decide to use the proven-interoperable ODF format instead … do you really want to cut yourself off from being able to work with those customers?
Edited 2006-08-22 10:29
“You miss the point entirely. Zoom. It has gone a zillion miles over your head.”
Oh, sorry. Forgot that Microsoft is out there to make our lives worse, even if it hurt their business
Even if some of the points you make are possible in theory, I don’t see any indication of them happening.
The fact is that Microsoft gives much more information (specs in ECMA) than previously and for free (specs, blogs) so I see that the situation is much better than few years ago.
“If you opt to use Office 12 and Office Open XML, it is possible to put something into a document you are writing that will mean that anyone who wants to open it (even yourself years form now) will HAVE to be running an application on a Windows platform. You may not even be aware you have locked yourself in until it is way too late.”
I’m not sure, where you get this thing that you are locked on a Windows with Office Open XML? Could you elaborate a bit more about this, technically or with some link (source)?
I agree that 100% compatibility across platforms is not easy (or impossible) to achieve with Open XML, but I don’t think Microsoft has ever claimed it to be possible or a goal, anyway. It is representation of the Office -format in XML, period. There are no binary fields or encrypted content or other obfuscated content by default in the saved documents.
On converted legacy documents there may be some embedded objects like ActiveX controls etc. It is true that these won’t convert to another platform. Usually it means that something more complicated is built on Office, anyway.
The same thing is true for any feature that is not supported on another applications: you can never be 100% certain that the other app or some future version supports it. Say, SmartArt etc. Even if they are fully documented, it is not guaranteed that anyone else supports them (see the W3C specs vs. browser support).
“If many years later you open the document you create next year with Office 12 using a later version of Office or of Windows (or with anything other than the current set of dependencies), you also run a risk of not having access to all of the features of your own document … let alone anyone else’s document. ”
Microsoft has always invested in backwards compatibility, so I wouldn’t worry about that. You can still open very old Word, Excel and even competitor format documents with the latest version of the Office. Why would they change this in the future, as it would certainly drive people away from MS Office?
About rest of the usual Microsoft-related conspiracy-theories:
I feel now much more confident that I’ll be able to save my data from Open XML -filesin the future. Unless there is DRM-protection set by the me, I can always open the zip and extract the text data (with or without formatting, doesn’t matter) and convert it to another format.
Also, if I really were worried about the data and work put into those documents, I (or any company) could design a system where I take in Open XML -file, extract the relevant information and save it to a database, ODF or any other format automatically.
You can override the saving event in the Office or you can start a workflow in SharePoint that makes this happen. This wouldn’t be near as easy with the current binary formats.
“If your customers decide that they do not want to run a similar risk, and they decide to use the proven-interoperable ODF format instead … do you really want to cut yourself off from being able to work with those customers”
If you use MS Office, you can use the ODF-plugin to work with those customers and convert documents when needed…
//I’m not sure, where you get this thing that you are locked on a Windows with Office Open XML? Could you elaborate a bit more about this, technically or with some link (source)? /
http://lxer.com/module/newswire/view/64829/index.html
http://www.consortiuminfo.org/standardsblog/article.php?story=20060…
“Sun, on the other hand, responds as follows:
To the best of our knowledge, the MS-provided option to integrate the converter software into the MS Office menu choices exists only for Word, and depends heavily on undocumented MS Office interfaces. Accessing the conversion software via these particular menu items may be possible, but we anticipate it would lead to a fragile implementation that could be disrupted by MS Office patches or other code changes.”
http://www.mass.gov/?pageID=itdterminal&&L=4&L0=Home&L1=Open+Initia…
http://www.topxml.com/XML/re-34771_First-impressions-of-Open-%2…
“A new draft of Open XML came out on my birthday. 4081 pages of PDF, and very impressive for anyone who has worked on specification and standards. Two things stick out: first how horrible XML Schema fragments are when stuck inline to document structure; second, how the implementation-neutral tone of the introduction is at odds with the elements for various kinds of Active X embedded objects.”
//I agree that 100% compatibility across platforms is not easy (or impossible) to achieve with Open XML, but I don’t think Microsoft has ever claimed it to be possible or a goal, anyway. It is representation of the Office -format in XML, period. There are no binary fields or encrypted content or other obfuscated content by default in the saved documents. //
It is not a goal of Microsoft’s for Office 12 and that is THE problem with Office 12. It is a showstopper. A killer. It is unuseable.
BTW, you are wrong about the binary blobs and obfuscated content.
//The same thing is true for any feature that is not supported on another applications: you can never be 100% certain that the other app or some future version supports it. Say, SmartArt etc. Even if they are fully documented, it is not guaranteed that anyone else supports them (see the W3C specs vs. browser support).//
You are wrong about this too, if you have fully documented, open and unencumbered standards, such as ODF. With those characteristics, one can indeed have a future-proof method of digitally storing documents. This is the exact reason why a body such as the Australia National Archives is a founding member of the ODF fellowship.
Office Open XML, however, is fully susceptible to the problems you mention here.
//Microsoft has always invested in backwards compatibility, so I wouldn’t worry about that. You can still open very old Word, Excel and even competitor format documents with the latest version of the Office.//
Not true. Quite a long way off the truth, actually.
//I feel now much more confident that I’ll be able to save my data from Open XML -filesin the future. Unless there is DRM-protection set by the me, I can always open the zip and extract the text data (with or without formatting, doesn’t matter) and convert it to another format. //
This would be a correct statement if you applied to to ODF. Since you apply it to Office Open XML, however, with its included binary blobs and platform dependencies, you are again mistaken.
//Also, if I really were worried about the data and work put into those documents, I (or any company) could design a system where I take in Open XML -file, extract the relevant information and save it to a database, ODF or any other format automatically. //
Actually, OpenOffice itself is the best option for this right now if we are talking legacy format MS Office documents. Office Open XML will be better at the Microsoft lock-in, though, and you will ONLY be able to do this in the future with Office Open XML if you run your convertor application on Windows. Since you still need Windows, then the assumption is the Microsoft are still around, so you don’t need to convert. If you need to convert, then there is presumably no Microsoft, and you can’t be sure you can convert … catch 22.
//If you use MS Office, you can use the ODF-plugin to work with those customers and convert documents when needed…//
Better option by far is to avoid the whole mess and shun Office 12 and Office Open XML right now.
“It is not a goal of Microsoft’s for Office 12 and that is THE problem with Office 12. It is a showstopper. A killer. It is unuseable.”
I disagree.
“BTW, you are wrong about the binary blobs and obfuscated content.”
I just tried it (again) with the latest beta. Made a simple document with some text and vector graphics. Renamed the .docx to .zip and opened each XML in a text editor: everything was standard, clear XML. No binaries anywhere to be seen.
“//I can always open the zip and extract the text data”
“This would be a correct statement if you applied to to ODF. Since you apply it to Office Open XML, however, with its included binary blobs and platform dependencies, you are again mistaken. ”
I just tried it, like I said aboce. Explain why it isn’t suddenly possible?
//I just tried it, like I said aboce. Explain why it isn’t suddenly possible?//
You would only get the text data.
If you stored your document in ODF in the first place, the full featureset of the document is guaranteed to be accessible in perpetuity, even if there were no Windows computers to be had any more.
“You would only get the text data.”
Wrong. If you embed external media, like jpg/png etc. images, they are normal picture files in the Media-folder in the zip-file. I just verified and there is no problem with that.
To get the vector image, I would have to parse the coordinates etc, of course. But the data is still there in normal XML.
I’ve yet to see anything impossible to parse from even an more advanced document.
//I’ve yet to see anything impossible to parse from even an more advanced document.//
Nevertheless, the engineering opinion is still: “it appears that a fully compliant application implementing MS XMLRS can not be implemented on non-Windows platforms”.
That is what anyone would think as soon as they saw the myriad references to Windows-only functionality in the Office Open XML speciification. It is rife throughout the document, it is chock-full of Windows platform dependnecies.
Despite your simple experimentation, it is possible to embed obfuscated binary blobs in relatively uncomplicated documents, and in fact it would be impossible to avoid doing that as soon as the number of documents stored in the format got past a few dozen.
Any business that opted to use Office Open XML would lock themselves and their documents in to a Windows solution in no time flat.
And I re-iterate, there is a perfectly viable and simple solution – use ODF instead. This avoids lock-in completely. It is even possible to use ODF and reduce your license compliance costs dramatically.
Edited 2006-08-22 14:02
//I’m not sure, where you get this thing that you are locked on a Windows with Office Open XML? Could you elaborate a bit more about this, technically or with some link (source)?//
http://www.consortiuminfo.org/standardsblog/article.php?story=20060…
“While we have not performed a complete assessment of the MS XML reference schema submission to Ecma, there appear to be many such features embedded in the format. In other words, it appears that a fully compliant application implementing MS XMLRS can not be implemented on non-Windows platforms. We believe this is also the case for a variety of proposed MS Office 12 functionality, including encryption features, digital rights management, etc.”
http://www.onlamp.com/pub/a/onlamp/2006/07/27/what-is-opendocument….
“The ECMA specification for Office Open XML reveals that Microsoft intends to tie functions within its Office 2007 office suite, functions within its new Vista operating system, and functions within its Exchange Server and SharePoint Portal Server to its new, XML-ready document file format. Continuing to tie the new XML file format not only defeats the design objectives of XML, but clearly perpetuates a familiar control by the company over customers’ document data and software upgrade cycles.”
“Why not just use OpenOffice or StarOffice right now?”
Because they suck and MSO is a better and more usable product. What’s so hard to understand?
“If you opt to use Office 12 and Office Open XML, it is possible to put something into a document you are writing that will mean that anyone who wants to open it (even yourself years form now) will HAVE to be running an application on a Windows platform. You may not even be aware you have locked yourself in until it is way too late.”
No, it just means that particular part of the document will not be available. Microsoft HAS to support legacy stuff like OLE objects or else they’ll just piss off customers. It would be bad for business, and that’s what matters. They are not doing it to “lock” you in, even if you are convinced so.
Edited 2006-08-22 15:40
//Because they suck and MSO is a better and more usable product. What’s so hard to understand? //
But MSO is platform specific (it requires Windows to run), available only from a single source vendor, and demonstrably not future proof. It has lock-in written all over the specification.
MSO is unuseable from any sort of objective viewpoint as an end user who has an investment in long-term valuable data. MSO is totally unsuitable for electronic document archival. MSO is not compliant to standards. MSO is demonstrably unuseable for document interchange.
Any one of half a dozen other Office suites (which by the way do not suck) are significantly better in every respect mentioned here.
What is so hard to understand?
What’s so hard for YOU to understand? All this tripe you go on about is a valid concern, but it doesn’t affect most people and most honestly don’t care. MSO is a better PRODUCT, AND is common place in business. Most data is short-lived, and any disadvantage of not being readable down the road generally isn’t a concern, and even less so with OpenXML.
//All this tripe you go on about is a valid concern, but it doesn’t affect most people and most honestly don’t care.//
Answered in the post above.
Use ODF and you will be guaranteed to future-proof your documents, make it possible for yourself to switch to another platform at a later time if that is what you decide to do, allow you to run a mixed-platform shop if that is what you decide to do, guarantee the ability to exchange documents with other firms that do not run a Windows shop, and be a company that can claim it is compliant to standards.
//MSO is a better PRODUCT, AND is common place in business.//
It is common place in business (through lock-in and inertia), but now is the ideal time (as MSO is changinging its format) to escape that lock-in.
MSO is not a better product for the reasons I outline – unless you use MSO with your document set saved exclusively in ODF format (if that option is even allowed you).
It is all upside to use ODF. It is all downside to risk using Office Open XML.
Nice job not even addressing my main point and just regurgitating the same thing over and over.
//All this tripe you go on about is a valid concern, but it doesn’t affect most people and most honestly don’t care. MSO is a better PRODUCT, AND is common place in business. Most data is short-lived, and any disadvantage of not being readable down the road generally isn’t a concern, and even less so with OpenXML.//
Trying to make you understand this point is very difficult, but perhaps this link might help explain why sensible end users of software are moving away from lock-in proprietary solutions such as Microsoft’s.
http://business.newsforge.com/business/06/08/11/1855229.shtml?tid=1…
“Interoperability, transparency, and money”.
Certainly it should help to dispel your myth that people don’t care about this. Au contraire, they care very much.
Edited 2006-08-23 00:23
No, most people do not care.
As long as they use a decent product and it works, that’s all that matters.
//No, most people do not care.
As long as they use a decent product and it works, that’s all that matters.//
Why won’t you Windows fanatics LISTEN?
This topic of lock-in to a sole source vendor and avoiding it as an end user DOES matter. It matters a great deal to a whole range of people.
In some case, it matters to entire governments of some countries (eg Croatia) and some states (Mass).
What will it take to make you listen?
Edited 2006-08-23 09:16
Governments are the biggest group that does care. However, that does not change the fact that consumers on a whole do not care. How many times do I have to repeat this to you?
Customers DO care…BUT they only care when a proprietary vendor stops development of a product they love.
Case in point: The mass exodus of DEC customers to UNIX after DEC dropped the PDP-10 and all PDP OSes in favour of VAX/VMS.
Another case in point: The annihilation of the PowerMac and the hobbyist/home hardware vendors of the 80s. x86 hardware has been (mostly) better than the Amiga for quite a few years, but it wasn’t when Commode went bust. And on the features that AmigaOS shares with Windows, AmigaOS STILL wins hands down.
I won’t argue that because you’re right. If it wasn’t clear, I only meant customers do not care about what he’s claiming.
Actually, I missed something. I would suspect (nevermind hope) that a lot of people who get burned by closed *ware and choose to go open never go back.
I certainly won’t.
What will it take to make [Windows fanatics] listen?
A brain?
The Open Office XML specification will be fully available through ECMA, that controls it. That is, once it is ready. Currently it is still in beta so not everything is available.
There are also no limitations on who can read/write Open Office XML -files: http://blogs.msdn.com/brian_jones/archive/2006/08/04/688932.aspx
And poorly documented?
http://blogs.msdn.com/brian_jones/archive/2006/06/01/612952.aspx
“I came across this the other day while I was looking through the ODF spec and comparing it to the Ecma draft trying to get a better handle as to why the ODF spec was so much lighter (700 pages compared to 4000).”
There are actually things missing from ODF specs and Open Office has had to do their own non-standard extensions to support the features missing in specs.
//There are also no limitations on who can read/write Open Office XML -files://
Apart of course form the restriction that the reading and the writing must occur on a Microsoft Windows platform in order to fully implement the Office Open XML specification.
No cross-platform capability for YOU! (as an Office Open XML slave^h^h^h^h user).
Also: No future-proof capability for YOU! (as an Office Open XML slave^h^h^h^h user) – because if Windows in the future is not available or possibly even just a different version – then you won’t necessarily be able to read your own documents you create in the near future (perhaps next year … maybe) with Office 12.
//And poorly documented?//
No, that Office Open XML includes proprietary binary blobs of undocument format and Windows platform dependencies is indeed a quite well documented fact.
//There are actually things missing from ODF specs and Open Office has had to do their own non-standard extensions to support the features missing in specs.//
ODF is a vendor-neutral format, it does not equate to Open Office. There are at least four independant and complete implementations available right now, today (they are not vapourware like Office 12 is). There are only a very few problems with data exchange between various ODF implementations (that are steadily being resolved), even implementations written to run on different platforms. ODF is cross platform.
If it were true that “there are actually things missing from ODF specs and Open Office has had to do their own non-standard extensions” then this cross-platform interoperability and interoperability between products from different vendors would not be possible.
We have an excellent example of products that are vendor (read: application) dependent and platform dependent in MS Office products. ODF is the opposite.
ODF specification is a fair bit lighter than Office Open XML specification because the ODF specification calls up other open and vendor-neutral specifications for some components – such as SVG and PNG and ZIP for example.
Edited 2006-08-22 08:05
“Apart of course form the restriction that the reading and the writing must occur on a Microsoft Windows platform in order to fully implement the Office Open XML specification.”
Proof? The ActiveX etc examples apply only to those documents that explicitily use them. The truth is that most people don’t use all the possible features. Many people just write text, change font and make it bold. Maybe even know how to use heading styles.
To get everything out of Office 12 or earlier versions doesn’t mean you have to use features that possibly cause interoperability problems. The new UI with ribbon should be reason enough to upgrade for many for productivity reasons.
The same applies with current versions: you can save and open “legacy” Word-documents with OpenOffice with no problems (so they claim). I don’t see how this is any different beyond Office 2003… (With “they” I refer to people that say that transition to competing suites is easy.)
You know, you can make documents with ActiveX etc. with Office 2003, too. Yet, I hear that people have no problems with OpenOffice when working with those .doc’s. Reason: people use primarily the basic features and rarely those that cause problems.
“ODF is a vendor-neutral format, it does not equate to Open Office.”
I know, but I used it as an example based on this (Numbering support in Open Office):
http://blogs.msdn.com/brian_jones/archive/2006/05/26/607630.aspx
There is also this part:
“In the latest Ecma draft, we [Microsoft] have about 200 pages discussing the syntax of formulas for spreadsheets, ODF has a few lines. That gives me the impression that no one that does accounting or works on Wall Street was involved in the standard because I can’t really imagine them allowing it to go through without specifying how formulas should be represented.”
Not sure how the different products support the formulas as there are no specs. I don’t think this is a minor problem with a spreadsheet…
Of course, ODF is still work in progress, but this can cause problems if/when the specs change. What happens to current ODF-files? Will they open in the next OpenOffice (or whatever ODF-compatible office?)
//To get everything out of Office 12 or earlier versions doesn’t mean you have to use features that possibly cause interoperability problems. //
Au contraire, the fact that Office Open XML has interoperability problems built right in to the design of the format guarantees this will be a major problem long into the future.
The best way to avoid this major showstopper headache is to use a format with open-ness, platform neutrality and non-obfuscation built right in to the design, as the major design goal of the format.
Read up on SOA, the MA ETERM, and ask yourself why MA really chose the way they did in the very first place.
Minor actually, since so few people actually use the features that would cause cross-platform issues.
But whatever, believe what you want. You’ve clearly illustrated you will, and are making this out to be a much bigger issue than it is in reality. Going on theoretical issues doesn’t work in the real world kid. Office has been out for who knows how long, and most people have no issue with it, even being a propietary format.
//Not sure how the different products support the formulas as there are no specs. I don’t think this is a minor problem with a spreadsheet… //
They are working on the specification right now.
In fact, the exact same problem was intrinsic to the Office Open XML specification in its first three drafts as well.
It wasn’t until the ODF camp started to work on specification of the formulas that the Office Open XML people also began to work on the same thing for theirs.
I can find you a reference for this too, but it will take me a while.
Edited 2006-08-22 13:22
Those four implementations of ODF aren’t even compatibile with each other. KOffice and OO.o have problems reading each other’s documents.
ODF is an incomplete spec. It even lacks a specification as to how to save spreadsheet forumlas. It lacks sufficient support for Asian languages. It’s slow. It’s not vendor-neutral, as it was derived from OO.o’s previous XML format, and therefore lends itself to OO.o’s code structure.
Public Enemy had it right: “Don’t believe the hype.”
//Those four implementations of ODF aren’t even compatibile with each other. //
Not true. Koffice originally had a bit of trouble with formulas. Fixed now.
http://www.koffice.org/announcements/announce-1.5.php
http://www.koffice.org/news.php
“More than 2 months before the final release, the KOffice team is happy to present you the first preview of the newest 1.6 version. This release includes mostly new features in Kexi and Krita, scripting support in KSpread and OpenDocument support in KFormula.”
//It even lacks a specification as to how to save spreadsheet forumlas. //
This was a problem to start with:
http://software.newsforge.com/software/05/09/09/192250.shtml?tid=93
But it is not true any more:
http://en.wikipedia.org/wiki/OpenDocument_technical_specification#S…
leads to OpenFormula:
http://en.wikipedia.org/wiki/OpenFormula
http://www.dwheeler.com/openformula/
//It lacks sufficient support for Asian languages. //
Not true.
http://www.zdnetasia.com/news/software/0,39044164,39380446,00.htm
http://www.openmalaysiablog.com/2006/07/odf_proposed_to.html
//It’s slow.//
Myth. Early versions of OpenOffice were slow, BEFORE OpenOffice began to use ODF.
//t’s not vendor-neutral, as it was derived from OO.o’s previous XML format, and therefore lends itself to OO.o’s code structure.//
Not true. OpenOffice’s previous formats (.sxw etc) are not ODF compatible.
//Public Enemy had it right: “Don’t believe the hype.”//
Don’t believe MS propoganda you mean.
http://www.robweir.com/blog/2006/07/throwing-stones-at-people-in-gl…
Edited 2006-08-22 15:05
“The Open Office XML specification will be fully available through ECMA, that controls it. That is, once it is ready. Currently it is still in beta so not everything is available.”
It will be nice once it is out there. I pretty much ignore MS Blogs anymore as oftentimes they have what the employees have been told, rather then what MS actually does with it after it is written. It will be a good day when/if it happens, but it does remain to be seen.
“Anyone can write a program that can read and write these formats by following the open specification of them.”
Is that why Adobe threatened to sue Microsoft, forcing Microsoft to remove built-in PDF support from Office 2007? Yep, that sounds like PDF is a free-to-use “open” format, all right.
“Is that why Adobe threatened to sue Microsoft, forcing Microsoft to remove built-in PDF support from Office 2007? Yep, that sounds like PDF is a free-to-use “open” format, all right.”
Actually someone explained it in the thread, as I was not sure of it myself. They stopped Microsoft due to monopoly reasons, rather then patent. Read the rest of the thread please and it gets explained quite well.
Ah, my bad. I thought I read once on Wikipedia that Adobe suppressed alt. pdf-writers, but in any case it says otherwise now.
Open XML will be in the next version of Mac Office, so it’s doable on Macs. You can read about this in the MacBU blogs. Apple is one of the sponsers of the OpenXML project so it’ll work on Macs.
Novell’s Gnumeric spreadsheet implements SpreadsheetML (the spreadsheet portion of OpenXML), so it’s doable on Linux.
Those of you saying that OpenXML isn’t cross-platform because of embedded ActiveX controls, what about OO.o’s OLE support? The Windows version of OO.o can create an ODF document that contains OLE objects. Those OLE objects will be unusable on Linux and Mac since you won’t be able to activate them. So, ODF isn’t cross-platform either?
BTW, OpenXML’s OLE support is superiour to ODF’s. ODF saves OLE objects as binary blobs. OpenXML saves them as XML, if the corresponding OLE server app supports XML. So you can have a Powerpoint document containing an embedded Excel object that contains an embedded Word document. The OpenXML PowerPoint document will store the embedded Excel object as an XML (OpenXML, in this case) stream, which will in turn save its embedded Word object as an XML stream. So one can drill down the embedded OLE hierarchy and parse the objects just using XML. In ODF, the first OLE object encountered is a binary blob (and therefore, all embedded OLE objects within the hierarchy are just binary blobs).
hose of you saying that OpenXML isn’t cross-platform because of embedded ActiveX controls, what about OO.o’s OLE support? The Windows version of OO.o can create an ODF document that contains OLE objects. Those OLE objects will be unusable on Linux and Mac since you won’t be able to activate them. So, ODF isn’t cross-platform either?
You aren’t likely to get a response on this issue. ODF “openness” proponents are busy licking their wounds.
If people want OLE support in Linux, people will implement it.
Most people on any OS will go on being ignorant of OLE no matter how cool the pronunciation is supposed to be.
Well, it is for some users anyway:
http://www.apcstart.com/site/admin/2006/08/1087/how-vista-screws-du…
As such, it’s a matter of some of the management at Microsoft getting their heads out of their collective posteriors and waking up to the fact that interoperability isn’t just a vague desire of some consumers – it’s the single most important one.