Thanks, I appreciate it.

“The difference WRT the security issue is that we own the source to MSXML. When, not if, a security issue is discovered, we can fix the issue and release a patch without having to worry about any encumberance [sic] due to various intellectual property rights [related to libxml] (which will vary according to the specific licenses involved).”

Do they force you to drink the kool-aid or is it voluntary?

Now if you add the fact that the new Office file formats are standarized by ECMA and possibly ISO, you can expect both projects to be slowed down.

I wish MS didn’t choose that .net path, it sounds like MS is gradually losing all its x-platform knowledge (now concentrated only in the MacBU).

I believe that Mac office 2007 will be better than the Windows one, as alrealdy happened with the 2004 release.You made a very good job. Many collegues of mine bought a mac also for mac-office 2004.

I have two questions:
1)what can be done with Real-Basic to fill the gap left by VB?
2) Apple-script seems to be very powerful, since it would also provide full access to other OSX resources, which have been unavailable with VB. Then, you are going to leave the effort of “low-level programming” to apple-scripts, because of all the tech reasons explained in your post.

My second question is: are there chances to see the same script-code being interpreted by Apple script in OSX and by VB in Windows?

I may have this wrong but it was my understanding that parts of the Windows networking stack is built on opensource code. IANAL but if I understand it right part of the beauty of the MIT license is that you aren’t going to have any property rights blow-back to worry about if you go ahead and use it in your proprietary software, so it’s disingenuous to say you can’t sleep at night for fear you going to get sued for patching libxml.

Realize I could be wrong on both of my above points. Frankly I’d consider using office again if it wasn’t the only mac app I’ve ever used besides Quark that can’t handle network shares. You know what I’m talking about. I’m much more worried about Office saving files to any format on a remote drive vs. what files it can open from the Win side of the world.

First, there wasn’t a single issue. That’s why I listed four issues that played a role in our decision. And, I’ll still stand by the statement that, at the time we made the decision, the version of LibXML that we could assume to be available on our minimum OS was not up to the task (which is actually what I said–I did not make a blanket statement about deficiencies in LibXML in general).

The difference WRT the security issue is that we own the source to MSXML. When, not if, a security issue is discovered, we can fix the issue and release a patch without having to worry about any encumberance due to various intellectual property rights (which will vary according to the specific licenses involved).

The point regarding security issues is not to claim that MSXML is more, or less for that metter, secure than LibXML. Rather, the point is the extent to which we control the ability to get a patch to our customers in a timely manner. Clearly, that’s far easier when we own the code.

It’s important to keep in mind that, unlike Apple, shipping open source components as part of our software isn’t a part of our business. So, while Apple can afford to keep a paid staff of developers whose work is dedicated to open source changes and who do not work on any of Apple’s proprietary code, we can’t afford to do that. It’s not as though anyone here can wade into some open source code, fix a problem, and we can still sleep at night knowing we have an ironclad defense should someone raise the spectre of some violation of their intellectual property rights.

It’d be better if this was said flat out instead of saying there are features missing form libxml. Especially since the latter contradicts observed and reported behaviour. Namely, the fact leopard, openoffice, and other apps will support the “OpenXML” formats when the far majority use libxml to do it.

Not sure about the security issue problem. Whether you ship your own version of libxml or a port of MSXML, the security issues will be the same. There’s been potential/actual security issues found in both. Furthermore, Apple is in the same boat. They ship more than one version of libxml with OS X and even though it’s third party code, they still stay on top of the issues.

I guess my point is that simply saying, “The MSXML and libxml APIs are just too different to make using libxml feasible,” would be the most rational reason for not going with libxml.

With respect to libXml, there are some additional points worth considering:

1) 18 months ago, we hadn’t made the decision of the minium OS version that Office 12 was going to support.

2) Shipping an updated version of an open source library is a non-starter, for one simple reason: if there’s a security flaw in the version we ship, we’re on the hook for that security issue without having ownership of the code. The potential legal issues are too risky to allow us to go down that route.

3) We need more than just SAX2 compliance. We also need DOM support on the write side.

4) LibXML’s APIs all use UTF8 for string arguments (or, at least, the libXML that shipped with Panther did). MSXML uses UTF16. Since Win Office is written to MSXML, we’d either have to rewrite considerable portions of the code we port from Win Office, or write UTF16 wrappers around the API’s and the callbacks.

All of those combined to make a difficult decision fall on the MSXML side of the fence.

Go look on the Internets to see what Mac users thought of Word 6 compared to Word 5.1, and see why Microsoft re-evaluated their strategy.

This is, IM(Seldom)HO a mistake. A long time ago, in a galaxy far far away (about 1990) Excel had the same code base on Windows, Mac and even OS/2. Aldus also did this with PageMaker (tho perhaps they didn’t support OS/2). It requires effort and discipline but in the long run less effort than trying to keep some sync between different versions. Developer work is better leveraged. Testing is cheaper. Writing documentation is cheaper, assuming anyone still writes docs for apps. And finally it means you can release for multiple platforms at the same time.

I believe the Mac market moves to newer operating system (and processors ) far, far faster than the Windows market.

Also while your explanations of the difficulties in porting the file conversion plugin, VBA, and Office itself are extremely illuminating (and much appreciated), the sad reality is that Microsoft looks like a bunch of incompetents when faced with the reality that third parties have or are going to achieve the same goals far sooner. (I am referring to a perception rather than making an accusation.)

More recent comments above now lead to the logical conclusion that little old Text Edit is going to be able to read and write Word docx files before the real Microsoft Word for Mac!

Indeed it would be interesting to know if someone with access to the Leopard developer release could try this write [sic] now.

Note: I already find Text Edit does a far better job handling Cyrillic Word documents than the ‘real’ Word 2004 for Mac.

On a totally different topic, the news from Microsoft as to whether Office 12 for Mac is going to [finally] support right to left languages such as Hebrew and Arabic is deafening in its silence.

The MacBU has around 180 folks total.

The Open Office group has about 737 contributors according to their website.

I couldn’t find any definitive estimate on the size of the Windows Office development team size, but I would guess-timate somewhere in the 1500-2000+ range conservatively.

So to all the nay sayers and pessimists I would say you need to take a step back and get some perspective. The MacBU is working on Office 12 (4 apps here),and at least 3 other applications I can think of, all in some stage of development. And all of this with less than a third of the team of the “closest” rival application suite.

They deserve a round of drinks for their work, not a bottle of whine. Keep up the great work guys.

Having said that, I do not want my blog and comments page to become a referendum on Open Source and Microsoft’s corporate positions on it. I reserve the right to reject or remove comments that drift in that direction. Instead, please continue to focus on the topic at hand — namely the Mac Office 12 converters for the new Open XML file formats. Thanks for understanding.

Since Leopard isn’t shipping until some time in 2007 (late spring?) it would be impractical for us to require our users to have Leopard to do their file conversions, if we relied on its XML parser. As for SAX support as mentioned in Rick’s post, we were well into our development work at that stage having already determined that Panther didn’t give us the support we needed and Tiger, although a year old, was still not widely adopted enough to cover as much of our user base as we needed.

As much as we love it when Apple adds technologies to the OS so that we can remove code from Office, we can’t always make it a requirement too early.

Beyond that, you’ll have to talk to Rick — he’s the XML technologies expert in our group.

I appreciate the almost Sisyphean efforts the Mac BU undertake to bring us our premium suite. But sometimes it really does seem to even a sympathetic observer like me that for whatever reasons you forever end up doing things the hard way!

Fingers crossed for a great Office 12 … “2008″ maybe? So long as it comes out in ‘07!

pardon?

It’s open source to that you CAN contribute.

And it’s MIT-licensed, so you don’t have to. If you want, you can add your needed features to it and bundle this enhanced libxml2 with Office without publishing your changes.

But probably you don’t even need that. Rick’s post (which you link above) explicitly refers to the version of libxml2 that shipped with Panther (2.5.4). Libxml2 2.6.16 (which is shipping with Tiger, and is also include in the latest Panther update 10.3.9) supports SAX2. And if that’s still not enough, you can bundle a newer version with Office.

Well, there is if your priority is the new version and not compatibility for the old. Err…forget I said anything.

But, there’s something else I don’t understand. You make it sound like the converter has to be hard-coded into Office 2004. My (and I would guess, most people’s) assumption was that it would be a plugin…At least, I always thought the file format readers/converters/savers in Office were modular. Guess I was wrong.

As for OpenOffice having their support done first, they aren’t also implementing an entire new version of Office simultaneously, as I noted that we are doing.

ChrisG, libxml is open-source, so I can’t contribute to its implementation.