Just wanted to respond to some of the comments by Stephane on my previous post. I was going to do this in the comments, but it was getting a little long, as you can see, so I decided to make them a post of their own.
24 years, and yet you don't seem to make a difference between a software vendor and a monopole.
First, just want to point out I was referring to 24 years of life experience, not industry experience. (As in, I was referring to a life lesson, and this wasn't a rule that applied only to technology). In fact, I'm only 24 years old.
That said, I don't understand what relevance the fact that Microsoft is or is not a monopoly... (unless you really were referring to the noun monopole, in which case I don't understand either).
"How can you get more interoperable than that?"
Too broad a subject to deal in one post. Let's get started with something simple : why wouldn't Microsoft support their own products?
"I'm just curious - how exactly does Microsoft not support their own products? "
Let's just talk about the latest that got me. See Excel 2003 xml, a departure from previous Excel versions. If you read the papers, it's near the best thing since sliced bread. Now, try it, and see for yourself that the xml in Excel 2003 does not support shapes, charts, VBA macros, and other rich objects. When you see how much this xml interoperability is being campaigned as a way to dimiss (proprietary) file formats, the lack of comprehensive Excel support in...Excel xml is a clear show stopper for everyone.
What's your point?
If you are using support to mean backwards compatibility, I think that's one of Microsoft's strongest points. Anyone who went to PDC (I didn't) saw the demo of VisiCalc, a 20 year old application, running on Longhorn. Another example is the Win32 API - and the fact that this remains in Longhorn, but as a wrapper for the managed code which is at the core of the OS.
This committment is just as prevalent in Office 2003. The introduction of a new way of storing documents - XML - doesn't preclude that prior support.
I'm not familiar with the specifics on what is and isn't supported from a legacy perspective in the new XML format, but I fail to see how that's a clear show-stopper for using XML for new spreadsheets. If you have “legacy“ documents that have things that aren't supported in the new version, you can continue to use that old proprietary format. What's the problem?
In addition, this does not preclude the ability of Microsoft to change xml over time, breaking third party software that would take advantage of xml, instead of using the usual automation API. In other words, there is no incentive to use xml now, especially if your business is around Excel.
Of course, to be on the positive side, you could expect those future changes as opportunities to add all the missing stuff in Excel xml. As a corollary, does this mean today customers have to wait Office.NET before Excel xml is useable just like Excel is today with BIFF? Please also note there is no business value in the xml file format : no new Excel 2003 feature actually that would have taken advantage of being xml-based.
It doesn't preclude them from changing the automation API either. But they don't change it significantly, and I doubt that Microsoft would arbitrarily change the general XML structure either.
I don't see this as a reason to avoid XML, but rather a reason to use it.
The whole point of XML is that it's extensible. It provides you with a level of flexibility that is unachievable a static API. In fact, I've worked with systems that used XML as the single parameter between layers specifically for this reason.
Let's say you want to add a property to a Cell node. If it's XML, just add (or look for) an additional attribute on the node. How would you do this without changing the automation API?
And even if the structure did change significantly, we can just transform it with an XSLT first and not change any of our internal code. How would you fix your application without code changes when the API changes?
"But instead, many in the Java camp just berate Microsoft and continue to point out that “they did it first” and “Microsoft just ripped us off”. Great way to compete, guys. "
I don't see a problem with it. Microsoft is doing great things now, and is obviously doing things much better and much faster than any other company in the world with .NET. Anything that goes on top of .NET apps is a radical change for say C++ programmers, and that spirit was introduced by Java. This has nothing to do with comparing how is Java now and how it compares with .NET now. It's only that there is blatant prior art here, and that Microsoft only better industrializes the stuff, thanks to the tools they have forged over the years.
I still don't quite understand the point you're trying to make.
I'm not saying that the Java folks are right or wrong in saying that Microsoft copied them - that's irrelevant. Personally, I do think Microsoft basically went about to build a better Java.
Java was extraordinarily innovative 7 years ago. I'm not trying to compare what Java was then to what .NET is today. But it does in fact have everything to do with comparing them today. Java's innovation in the past doesn't necessarily make it innovative today. They rested on their laurels, and Microsoft caught up (and then surpassed) with .NET.
Now, I hope that changes - if Java counters with something better than .NET, the ensuing game of innovation leap-frog will only help us all - as developers and consumers of technology.