Slashdot Log In
Dark Corners of the OpenXML Standard
Posted by
CowboyNeal
on Thu Jan 04, 2007 11:54 PM
from the dared-to-comply dept.
from the dared-to-comply dept.
Standard Disclaimer writes "Most here on Slashdot know that Microsoft released its OpenXML specification to counter ODF and to help preserve its market position, but most people probably aren't aware of all the interesting legacy code the OpenXML specification has brought to light. This article by Rob Weir details many of the crazy legacy features in the dark corners of OpenXML. As it concludes after analyzing specification requirements like suppressTopSpacingWP, 'so not only must an interoperable OOXML implementation first acquire and reverse-engineer a 14-year old version of Microsoft Word, it must also do the same thing with a 16-year old version of WordPerfect.'"
This discussion has been archived.
No new comments can be posted.
Dark Corners of the OpenXML Standard
|
Log In/Create an Account
| Top
| 250 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
It's not a true standard... (Score:4, Funny)
(http://www.creimer.ws/ | Last Journal: Friday January 26 2007, @12:40PM)
Length (Score:4, Funny)
Size (Score:5, Funny)
(http://kadin.sdf-us.org/ | Last Journal: Tuesday October 16, @01:46PM)
And the best part is, these [umn.edu] are the pages it uses... (I mean, why else do those specs cost so much?)
Re:Size (Score:4, Funny)
(http://www.notaclue.info/)
MS areslow learners (Score:4, Interesting)
Their "open" XML format for office docs is a prime example of this.
I think Steve Jobs was the one who first said "Microsoft just doesn't get it". Microsoft was probably the very first third-party software developer for the Mac and this was Jobs' reaction to Microsoft's first Mac applications (I think a port of Multiplan--which was re-incarnated into Excel IIRC, and MSBasic). They really WERE "tasteless", ugly and took almost no advantage of the revolutionary GUI interface--their DOSness really showed through--I think in the case of Multiplan the mouse could be used only to jump the cursor to a certain cell and that was it--the rest was all like in DOS.
MS Windows is another example--Microsoft didn't "get it" well enough until the third major release. Now MS is SLOWLY "getting it" with the beneficial characteristics of XML standards. Microsoft's early XML efforts are like Windows 1.0--there is some very rudmentary understanding of the mechanics but not the philosophy of XML, and I wonder if this is why SOAP ended up NOT so simple (given Microsofties were involved in its creation and seemed to be trying to make it a DCOM-in-XML-but-dumber thing). Microsoft's "Version1" XML might look like this: "See? We're using XML and SOAP! We're hip! We're cooool! You can't say we don't play by the rules now!"
Of course, this is an obtuse, opaque and obsfucated way to use XML andtotally NOT in the spirit of interoperability and openness. I won't even go into the nifty XML tools MS has made...nifty to use but they've done a lot to obliterate the S out of SOAP in their crazy output.
OOXML (Opaque and Obsfucated XML) standard is "version 2.0"--they're doing their best to eliminate ambiguity but now we've gone over to hyper-specificity, and the standard is being shared a bit better...problem is that they don't fully describe the interpretation of the standard elements so as to keep its advantage. All they've done is taken every formatting option and mapped it to an XML element--it is monolithic and completely non-extensible. But hey, at least its publicly available and doesn't involve weirdness like encoded-binary-blobs.
In a few years MS will reach version 3.0 of "getting" XML...
The author is exactly right. (Score:4, Insightful)
Re:The author is exactly right. (Score:5, Insightful)
Re:Isn't ODF an updated OpenDoc? (Score:5, Informative)
(http://ian.testers.homelinux.net/ | Last Journal: Sunday March 18 2007, @01:47PM)
Disadvantages of ISO (Score:5, Interesting)
(Last Journal: Thursday August 30, @10:31PM)
Once it is ratified as an ISO Standard, the standard is locked up and anyone that does want to a copy has to buy it from ISO. These are copyrighted. They're not cheap; thousands of dollars. Out of the reach of the average hobbyist, and not listed anywhere on the Internet. That 6,000 page draft will vanish into the mists of time.
Larger Companies can afford this, but garage companies and hobbyists definitely can't. So what's the chance of an open source or even small upstart challenging Microsoft's Documentonopoly? Zero.
Want another example? ISO country codes. The country codes (e.g. .us, .jp) are actually ISO, and ISO ended up backing off on a demand for royalties for this(!) But if you want state codes (e.g. California, Kantou), well, forget it unless you want to buy them off ISO. http://www.alvestrand.no/pipermail/ietf-languages/ 2003-September/001472.html [alvestrand.no]
ISO aren't the only ones guility of doing this. IEEE do it as well. Want the latest simulation standard? Then get out your checkbook: http://standards.ieee.org/catalog/olis/compsim.htm l [ieee.org]
ISO and the IEEE are enemies of openness. Microsoft is taking a page out of their gamebook.
ISO or IEEE certification is a *bad* thing.
The power of legacy systems... (Score:5, Insightful)
the real hitch - it never was clear (Score:5, Interesting)
(http://yro.slashdot.org/~twitter/journal/177855 | Last Journal: Sunday November 04, @10:56PM)
The hitch here is that *not* having them means tons and tons of reverse engineering, and that's only after tracking down every release of every version of every MS Office ever.
The real hitch, as the article hints, is that the releases are contradictory. For instance, the Mac version of small caps is different from others. This is part of the reason Word is so bloated and does not preserve printing type setting from one machine to the next.
Ten years ago, a state agency I was working for was forced to move from Word Perfect to Word. Hundreds, if not thousands, of documents were painstakingly converted from one format to the other. The typesetting, which they had never had a problem with previously, was easily broken by moves from one machine to the other or by changing printers. That is the kind of thing that no program can account for - it was broken from then and can not be created correctly today. It's also probably the reason for all of the nebulous "guidance" sections that don't tell you anything other than to look at, and presumably measure, old printed examples. Not even M$ knows what it was really doing in the field. As I saw at the time, no two were alike.
Of course, the time to get things right is not in your XML it's when you import the document. The author tells us this in so many words. The XML should be general enough to encompass any kind of typesetting. It is the importing program's task to figure out what the old format wanted things to look like. As the author points out, the spec does not do anything other create something impossible to follow. It's not going to magically make things look right no matter how hard they wish it would.
14 year-old Word and 16-year old WP (Score:2, Funny)
(http://slashdot.org/)
Basically (Score:5, Insightful)
(http://www.sympato.ch/)
OpenXML is Microsoft trying to translate its proprietary DOC file inside a XML container (because it's a big buzzword) and propose it as a standart to ECMA (because everyone is speaking about ODF being an ISO standard). It describes not only what is to be expected from a word processor, but also all MS-Word specific microsoftism. It was designed with a specific software in mind (and partly derives from the internal functionning of MS-Word). It's only a small improvement over the previous MS XML format (which had a lot of informations hidden in a binary blob).
The good thing for Microsoft, is that they can pretend this limitation is "Not-a-bug-but-a-feature", and brag around that there are a lot of stuffs that MS-Word couldn't store inside an ODF and only OpenXML can carry.
Microsoft's plan :
1. Embrace
2. Extend <- They are here
3. Extinguish
Don't forget the page counts... (Score:5, Interesting)
ODF spec page count: 722 [iso.org].
OpenXML spec page count: 6000 [regdeveloper.co.uk]!!
Re:Basically (Score:4, Insightful)
(Last Journal: Sunday March 21 2004, @11:14PM)
I would argue that when it's taken to the extreme of Office prior to 2007, it *is* a bad thing. AFAIK, the old Word format is more or less a (very) partial RAM dump (which is why you can often find all sorts of interesting stuff in Word files that the authors think they've deleted). That makes for faster dev times, but because the load and save functions don't really "understand" the content of the file, IMO the developers made things a lot harder for themselves in the big picture. I imagine reproducing issues in testing is a particular nightmare.
Re:Basically (Score:5, Interesting)
And about your RTF suggestion... can I draw diagrams with RTF? Can I have a ToC? Can I do complex styling? Can I have a "galery" of styles? Can I include images? No. RTF is not a solution.
Re:Basically (Score:4, Informative)
(http://www.soundepartment.com/)
After having written some tools on OS X that do stuff with RTF:
RTF is well documented and you can make an RTF document on all manner of platforms (I've done it in Ruby and Cocoa), but many platforms have extended RTF in their own way in order to support special features. OS X has added a few special methods to RTF files to support Mac OS X typography, and I've noticed that different versions of Word handle document attributes (like headers and page numbers) in different ways.
RTF is great if you want to make up something quick that is ONLY formatted text, but readers have all manner of different ways of interpreting the exact appearance of tables, page layouts and margins, and there doesn't seem to be any manageable common mechanism for including images or other documents, something Word and OO.org excel(pun) at. Even HTML seems to be better at this.
I use RTF output in a few little in-house tools I have, so people can get the text+attributes they create and open them in a text editor of their choice for touching-up and delivery. When my tools have to create something that is supposed to be finished, they make PDFs.
RTF is great for interoperability, but I never expect an RTF file to contain a "finished product," unless the recipient expects quality on par with a Selectric. It is merely a relatively-open serialization format for strings with attributes.
Documents outlive applications (Score:5, Insightful)
(http://www.geof.net/)
Documents are worth far more than software, and they outlive the applications used to create them. See the comment [robweir.com] to the original article - reading documents after 5, 20, 30, 100 years or more is not optional. You can pay the price of developing an independent format now, or you can pay the price of reverse engineering over and over again every time you change your internal representation.
Repeated implementation limits future change and innovation. It's expensive: it likely costs more even for Microsoft. But they can afford it; their competitors may not be able to. Plus, Microsoft already has their first implementation.
Perhaps so. But compare that cost to the cost I've just outlined. It is in the best interest of users and software developers (maybe even of Microsoft) to bite the bullet now, do the conversion once, and develop a clean format for the future.
Maybe you have in mind an argument you're not making, but I don't see any sufficient basis for your broad contention that using a file format based on an internal representation is a "darn good idea". In specific cases, yes (e.g. where the cost of development time or effort are the most important factors). In general, I very much doubt it. That successful applications in the past have taken that approach is weak evidence. They were developed when the up-front cost of development in a time of rapid innovation, the loss of customer lock-in, and a lack of open-format competition where good business reasons for making such a choice - even if it was inferior technically, increased cost in the long term, and was bad for consumers. In today's climate of slower innovation, competition from open formats, and customers who are running into their own long-term interests, the situation is different.
Which is not to say Microsoft's apparent attempt to set the rules of the game and throw sand in the gears of change is not in their interests, or that it will be unsuccessful.
OOXML's Origin Is Not The Problem (Score:4, Interesting)
(http://www.nymar.demon.co.uk/)
OOXML includes data elements that should be part of internal import routines rather than being enshrined in the document format, and it includes elements that are not specified except by reference to applications for which no public specs exist. This is the problem, not the fact that OOXML is derived from MS Office file formats.
Well, I was a big fan of RTF at one time. But a few years back I found that documents with any kind of formatting more complex than paragraph+justification+font just wasn't working between MS Office and back. I don't know if this was because the format couldn't cope, or because of faulty implementations. In either case, it led me to give up on RTF.In any event, to be a replacement, RTF would need to work for spreadsheets and presentations at a minimum - something I don't think there's a lot of support for in the current RTF specification. We'd also lose the benefits of an XML based format, which given the amount of work on the seamless integration of XML documents into databases, web services and other data management applications means losing a lot of functionality.
Interoperability is only part of the problem. We also want a spec that can be fully and freely implemented by anyone, which isn't under the control of any single vendor.We want a format to which we can entrust documents, knowing that in twenty years time there will be an application capable of reading them. I don't know what you mean by native in this case, but the repurposing of OOXML isn't the problem. It's one of size and obfuscation, and as TFA points out specification by reference to closed formats and the behaviour of extinct proprietary software. These are non trivial problems with OOXML which are not (to the best of knowledge) found in ODF.There's nothing wrong with ODF. Re-creating it based on the non-XML RTF would be a waste of time and effort.
Solution? (Score:1)
Death would be too easy. (Score:5, Funny)
(http://kadin.sdf-us.org/ | Last Journal: Tuesday October 16, @01:46PM)
At the same time we'll let the tech support drones have their way with the Microsoft campus, which I suspect will involve setting it on fire.
The site seems to be slow... (Score:5, Informative)
(Last Journal: Monday October 23 2006, @03:10AM)
So what can you do?
The solution is simple. Create a job description that is written specifically to your friend's background and skills. The more specific and longer you make the job description, the fewer candidates will be eligible. Ideally you would write a job description that no one else in the world except Guillaume could possibly match. Don't describe the job requirements. Describe the person you want. That's the trick.
So you end up with something like this:
* 5 years experience with Java, J2EE and web development, PHP, XSLT
* Fluency in French and Corsican
* Experience with the Llama farming industry
* Mole on left shoulder
* Sister named Bridgette
Although this technique may be familiar, in practice it is usually not taken this extreme. Corporate policies, employment law and common sense usually prevent one from making entirely irrational hiring decisions or discriminating against other applicants for things unrelated to the legitimate requirements of the job.
But evidently in the realm of standards there are no practical limits to the application of the above technique. It is quite possible to write a standard that allows only a single implementation. By focusing entirely on the capabilities of a single application and documenting it in infuriatingly useless detail, you can easily create a "Standard of One".
Of course, this begs the question of what is essential and what is not. This really needs to be determined by domain analysis, requirements gathering and consensus building. Let's just say that anyone who says that a single existing implementation is all one needs to look at is missing the point. The art of specification is to generalize and simplify. Generalizing allows you to do more with less, meeting more needs with few constraints.
Let's take a simplified example. You are writing a specification for a file format for a very simple drawing program, ShapeMaster 2007. It can draw circles and squares, and they can have solid or dashed lines. That's all it does. Let's consider two different ways of specifying a file format for ShapeMaster.
In the first case, we'll simply dump out what ShapeMaster does in the most literal way possible. Since it allows only two possible shapes and only two possible line styles, and we're not considering any other use, the file format will look like this: Although this format is very specific and very accurate, it lacks generality, extensibility and flexibility. Although it may be useful for ShapeMaster 2007, it will hardly be useful for anyone else, unless they merely want to create data for ShapeMaster 2007. It is not a portable, cross-application, open format. It is a narrowly-defined, single application format. It may be in XML. It may be reviewed by a standards committee. But it is by its nature, closed and inflexible.
How could this have been done in a way which works for ShapeMaster 2007 but also is more flexible, extensible and considerate of the needs of different applications? One possibility is to generalize and simplify:
zOMG (Score:1)
Backwards compatibility (Score:3, Interesting)
I can't see this being too big of a problem (Score:1)
(http://www.agaresmedia.com/ | Last Journal: Thursday June 15 2006, @04:05PM)
A) Desire to convert an old Word 5/95/WordPerfect 6 document to OOXML.
B) Have the original document actually use one of the undocumented legacy features
C) After converting the file actually experience a problem in formatting
First of all, the number of people who fall into category A is going to be small to begin with, same with category B. Although Microsoft is not providing the documentation like they should be, category C would be up to Corel, Sun, and other producers of future OOXML compatible word processors to implement. They're going to implement OOXML, so they're going to be encountering these issues as they program anyway. I trust they can figure out a way to display "full-width East Asian characters" and other such issues that are not fully documented in the standard.
Re:I can't see this being too big of a problem (Score:5, Insightful)
You do not need these features to begin with in a new format that is inherently incompatible with an old format. You don't want to say "now I'm going to do WP style linespacing and my linespacing is 1".
If you want to convert a WP document to an XML document, the conversion program should know that the linespacing in WP is 0.9 times the linspacing in XML document (or what it really may be)and will then use linespacing=0.9 in the XML document. This is not a task of the new wordprocessor or its specification.
By adding this so-called "backward compatibility" to your specification, you make the spec overly difficult and in fact you make the conversion program in the new application when this is absolutely not necessary.
And on top of that, you require that the programmer who uses this spec should have knowledge of all these old versions and is able to program them without error. And as the application will grow because of these unnecessary features, the number of bugs will also rise. So this is not a blueprint for a good application, this is a blueprint for a very buggy implementation of a wordprocessor.
My favorite quote (Score:4, Insightful)
Outrageously funny and to the point.
Not really a problem if ... (Score:1)
(http://alansplayground.spaces.live.com/)
Where I'm from, reverse-engineering... (Score:4, Funny)
(http://trollchat.org/)
Unfair (Score:1)
If they take the first option, then writing a tool that converted to and from OOXML would be a nightmare, you'd have to work out all those broken options into something that looked right, even if the end application supported it natively, since the converter app would be the last chance to attempt this obscure conversion. Making the old format->OOXML->old format loop actually end with a document that rendered anything like the starting document would be pretty much impossible.
The way they did it, a converter app that reads in those standards can just set the appropriate flag, and let the downstream renderer deal with it. If the user actually needs these crazy old features they can go get a patch to their wordprocessor to support it; or they can find a special-purpose converter that modifys the document to not need the flag anymore; or they can convert the doc back to the original obsolete format and open it in the ancient app itself. If the document had already been mangled by a half-baked conversion/export tool, the user couldn't have done any of these.
Tools that don't care about legacy support are unaffected by this; they can just pick the closest modern option to whatever the legacy flag calls for on input, and not output documents that use them.
Re:Unfair (Score:4, Insightful)
(http://davecheatham.com/)
Tools that don't care about legacy support are unaffected by this; they can just pick the closest modern option to whatever the legacy flag calls for on input, and not output documents that use them.
And thus tools, legally, are not OOXML, and won't qualify for purchasing by companies that specify OOXML. Which is the entire point.
There's a difference between 'We need to make sure that old documents can be converted correctly.', and 'We will literally convert old documents into a new representation that contains all their weirdness, and we won't explain how to implement said weirdness in the standard.'.
What Microsoft has produced is not even a standard. Standards must specify everything, or reference other standards that specify everything. They can't reference applications.
If Microsoft wants to keep secret how to turn Office 95 documents into OOXML, fine. Producing a standard doesn't mean you have to explain how to convert things into that standard.
It does, however, mean you have to explain exactly what should happen if mwSmallCaps is true, to the pixel. You can't just pawn it off on the unexplained hypothetical behavior of some other application.
Application responsible for converting? (Score:2)
When I save a Word 2007 document to the old
Forcing every new app ever written to this standard to support diffuse behaviours from the good ol'days is just ridiculus. Besides, most of it appears to apply just to apperance.
Even more lapses of judgment... (Score:2)
I'm can't believe this became a ratified standard.
"Let him who has understanding calculate the number of the beast, for the number is that of a standard; and its number is three hundred and seventy-six." Common-freaking-sense 13:16-18
- shadowmatter
Blind leading the blind (Score:3, Interesting)
(http://silmaril.ie/cgi-bin/blog)
OOo did the same, but with greater elegance and less haste because they were ahead of the field. Corel screwed it up with WordPerfect by keeping their stylesheet format proprietary so that transfer between WP document code and XML was made as hard as possible (a Class A blunder, given that their XML editor is actually quite good). AbiWord makes a good job of saving DocBook XML, but it's not trying to pretend it's reimportable; it screws up LaTeX formidably, though, by trying to pretend that it absolutely has to preserve line-length and font-size, which is evidence of the same neurotic attitude as Microsoft.
The problem in all cases is not that the assorted authors and coders don't understand XML (although some of them clearly failed that test too), but that they don't understand documents. This is particularly true at Microsoft, where leaders such as Jean Paoli have been proselytizing XML for years. They still think a document is a jumble of letters; they have no idea of structure, and the DOM is simply laughable as a non-model of a document. Microsoft's particular problem with XML is that they came to it too late, and viewed it as a way of storing data, not text...indeed to this day many XML users, trained with Microsoft blinkers on, are unaware that XML can be used for normal text documents.
With this level of ignorance surrounding Microsoft, it's hardly unexpected that they should blunder so badly.
Do backward compatibility in the converter (Score:2, Insightful)
purism as the enemy of progress (Score:2)
Seems fair enough (Score:2)
(Last Journal: Thursday April 18 2002, @07:50PM)
If you were faced with output from a 15 year old program, what would you do? 15 years? In software, that's an eternity. These tags are essentially saying "here is where this old crap used to be". How many people are actually using these programs? Maintaining documents in the old format? I defy any of you out there in Linux-land to say you wouldn't take the same approach under the same set of circumstances. Actually, Linux people would probably just say "it may not open old documents properly, but that's OK because you have the source". Really not much better.
Guillaume Portes = Bill Gates (Score:2, Interesting)
Looks the same--who cares! (Score:2, Interesting)
Named styles is the answer. If a paragraph is body text, call it that. If it's an inset quote, call it a quote. If a term is in italics, label it as italicized style not Times Italic 12 point. But don't get all hung up in the distinctions between Times Roman and Times New Roman. The purpose of XML is to define what something is. Not what someone thought it ought to look like on Tuesday three weeks ago.
Ditto transfers between applications. Why is there so much effort devoted to importing every little odd quirk of Word into InDesign as if the quirk mattered. Bring in the text tagged with what it is and let InDesign determine what it looks like. InDesign is far more powerful and predictable than Word anyway.
It is, of course, the Microsoft's advantage for everyone to define RTF and now OpenXML as the "standard" and obsess over the sort of things described above. But there's no sane reason for this obsession to exist. If you want a text to always look the same, use PDF. If you want a document to look good, make it look good in the application you're using. Don't try to make that application retain the 'sorta-looks-ok" feel of another application. That's too much work for too little result. It's why all too many ordinary users shrug their hands and buy Word rather than hassle with import quirkiness.
Typical FUD - To support OOXML 'fully'... (Score:2)
(Last Journal: Saturday April 03 2004, @07:10PM)
If I want to write a plugin for an open source text editor so that people can exchange word 2000 and later documents with my own editor I would certainly concern myself with supporting the aspects of OOXML which denote Word 95 emulation.
MS is lazy! (Score:1)
Yo (Score:2)
"Dark Corners"? (Score:1)
(Last Journal: Wednesday August 03 2005, @01:39AM)
Re:MIcrosoft sucks. (Score:2, Insightful)
Or maybe it was their illegal business tactics?
It would be pretty easy for me to run a successful business too if I could break federal law with impunity.
Re:MIcrosoft sucks. (Score:5, Insightful)
(Last Journal: Monday June 23 2003, @07:07PM)
Re:MIcrosoft sucks. (Score:5, Insightful)
(http://www.badstep.net/ | Last Journal: Tuesday December 30 2003, @06:04AM)
I think the Office XML format style is a play straight out of IBM's hand-book: make the standard complex and incomprehensible, and the little players - that's you - will find it hard to compete. In a way, that's a good sign: Microsoft is now lumbering into middle-age, hoist on their own evermore complex petard.
The other thing about middle-age is that every little technological step away from their established base-line is treated as a revolution. In reality, it's no such thing, just a small stepping stone to shouting "pesky kids. Get off my lawn." Or maybe they've reached that stage already.
Re:MIcrosoft sucks. (Score:4, Insightful)
(http://slashdot.org/)
Also don't forget that although MS's purchase of DOS was perfectly legal, it was ethically horrible. They arrived at a handshake agreement to license the code from Seattle Computer Company. While the MS paperwork was being finalized by the lawyers, SCC then made arrangements to finance other business ventures using the MS money. MS then presented them a contract to buy the code rather than license it, and told SCC to take it or leave it. As SCC had already committed to the other deals, they had no choice but to take MS's offer. Sure, no one held a gun to the head of the SCC executives forcing them to take the deal, however, they didn't have any other reasonable alternatives. MS's behavior was legal, but certainly not ethical.
Re:MIcrosoft sucks. (Score:5, Insightful)
Yeah. Because the person best suited to decide what a company should or should not be allowed to do are the people who own the company. Of course you're going to want to be completely unrestricted to mow down your competitors using whatever advantages you have if you are in a position to do so. What you're missing is that no one should be allowed to use unfair practices to do it. Some people think we should idolize the free market as some sort of religion. We don't like free market economy because it was given to us by the gods. We like it because it tends to result in better products and lower prices. That ceases to be true when you have a monopoly in the mix.
That being said, I'm not really informed about any Microsoft specifics, so I'm not going to argue in favor or against any "federal laws" as it applies to them (or failed to apply to them). However, suggesting that only people who have built a company that holds a monopoly should be able to decide what is fair regulation isn't rational. It may even be that the current federal laws regarding monopolies may be unfair and in need of reform, but the fact remains that the existence of a set of laws to regulate businesses is necessary.
Re:MIcrosoft sucks. (Score:4, Insightful)
Until you get to that point, I suggest that you those "federal laws" out your ass, Mr. Ashcroft.
Oh, and also those so-called "computer misuse" laws. Indeed, if I want to set up a consultancy where I propose to convert customers ASP scripts to PHP I should be allowed to demo to my prospective customers in great graphical detail why ASP is so insecure, even if I don't yet have an existing business relationship. Why should I tolerate that the government tells me how I may and may not recruit new customers?
Anything less would be one-sided and unfair.
Re:Suck it up (Score:3)
Re:Suck it up (Score:2)
(Last Journal: Tuesday April 12 2005, @01:04AM)
Forbidden partial implementation? (Score:5, Interesting)
(http://myatomic.com/ | Last Journal: Sunday November 19 2006, @12:31AM)
The behavior of years-old proprietary word processing software is included by reference into OOXML. How is any spec that includes by reference the behavior of proprietary software exactly "open"? True, implementors could produce a partial implementation of the spec that degrades away the legacy baggage (more or less) gracefully, but some standards' patent licensors forbid implementors to publish a partial implementation. I don't know if this applies to OOXML's license.
Re:Suck it up (Score:5, Funny)
Re:Suck it up (Score:2)
(http://www.vanderlee.com/)
Yes, we could all duplicate the significant effort of reverse engineering the missing parts of the standard (you still have a working copy of WP5 around somewhere?). Or we could just save everybody a lot of time and money in the future by making a one-time small investment of fixing the standard now.
Who's Scared? (Score:4, Informative)
(http://yro.slashdot.org/~twitter/journal/177855 | Last Journal: Sunday November 04, @10:56PM)
Eh? Isn't that why M$ made this supposedly "open" format? Because governments were tired of paying through the nose for secret formats that broke between versions? The purpose of an archive is to read it later. Governments and companies have already moved to pdf for archives. They are going to move their working documents to reasonable formats next.
But MS opened their own format, thus leveling the playing field so that you must again compete on features ...
You must not have read the 6000 page spec, which includes lots of sections like this:
That's neither open, nor a standard.
Microsoft is hoping people believe what you say, but everyone knows better. Shit like OOXML this only proves that they have not changed. It's just another, more elaborate and more expensive lie. Even the name, by using "OO" is intentionally confusing. The New Office is everything the old Office was and always will be. Vista and Office 2007 are non starters.
Re:FUD; you guys are scared to death (Score:1)
Some people just can't think past what's in front of their eyes.