I respect that view, more than that of ODF advocates playing politics. My question is: how much work does the spec need? Difficult to answer without a lot of research; many of those best equipped to comment seem to have entrenched positions or loyalties which undermine their remarks. It also depends I would suggest on how you want to use the spec. If you want to write an alternative to MS Office of course you will have a different view than if you merely want a stable, standardised document format with which to work.

> your reasoning allows for Internet Explorer-like strategies
> to prevent any form of competition in the market place.

I think you are proposing that standardising the MS Office formats in a way that only Microsoft can implement would impede competition. It would, if there were no alternative, and if you had to implement all or none. But neither of these is the case. I think a standardised MS Office document spec would assist rather than impede competition.

It’s also obvious that having governments or other institutions mandating that MS Office documents must NOT be used would/will assist the competition – but that strikes me as inflexible and potentially costly to productivity. I’d rather see products compete on merit rather than by regulation.

Tim

http://www.itwriting.com/blog/?p=116

- it’s sloppy work in my view and needs fixing. But I do want this stuff to work.”

I agree with the conclusion. It so happens I did not even have to actually test this thing to draw that conclusion.

1) The source code is very poor.

2) The requirements are unheard of (requires Office 2007 which in turn requires XP SP2, requires .NET 2.0)

3) the development reports that are part of the distrib show that half of action items have either no status or partial status. It has not stopped Microsoft from doing a PR around the world, boasting with an interoperability component that had just reached, quote, “complete” status, end quote. Of course, whoever has been following the JTC1 INCITS committee knows that they are doing a vote this Monday 5 feb 2007. Funny coincidence…

4) the development of the opposite way (OOXML to ODF) translator started only on December 2006.

5) the CleverAge guy already said on his blog back on October that the component would not support round-tripping. He said there were fundamental problems. It has not stopped Microsoft from telling the world that this component does interoperate documents, with no limitation whatsoever. Isn’t this a lie by omission?

I would like the TC45 committee to go back to the drawing board until the specs stabilizes. Ideally, an independent implementation should be evidence that the specs as a merit.

If you are ok with “progressive work”, I think that 1) you are taking the Microsoft party line (just like Miguel did last week, except that he’s still a Novell employee, therefore he has no credibility left whatsoever now), 2) your reasoning allows for Internet Explorer-like strategies to prevent any form of competition in the market place. Do I have to remind the progressive implementations that were plugged in it version after version and how the agenda was to move the barrier entry always higher with each new release?

To answer this question, I meant by “a simple example” the fact that VBA macros is not all that is missing in Ecma 376.

I’ll give you another example since you seem to be eager to hear about them. Password-protection. If you password-protect an Office 2007 document, it becomes an OLE document, not a ZIP file. Good luck finding any reference to the entire encryption/decryption mechanism in the specs.
If you do a keyword search for “password-protection” in Ecma 376, all you will find is an algorithm and a couple explanations about the hash key computed from the password string. The hash key is stored in the parts in order to perform the password matching later on. But it’s not the password-protection.

Without describing the password-protection in Ecma 376, Microsoft has very explicitely removed any such document out there from any kind of interoperability.

And it’s not like password-protected documents are not used out there…

I think it is a mistake to lump all kinds of documents together. If we are concerned with document interchange and analysis – importing, exporting, parsing and generating Office documents, a standardised format is useful. Frankly I hardly ever need to receive a document containing macros, and in most circumstances would regard it as impolite to send one out. If I were writing an application that would be different – but then I would want to know what platform the application would run on.

> This new attachment (see attribute CodeName in Ecma 376) is not described.
> In fact, in many places of the specs, the attribute is just described as
> a string with no explanation of the entire component life cycle
> that is serialized in it.

That sounds like a flaw in the specs. I am sure there are plenty of these; however I would like to see the spec improved and not destroyed, as to my mind it is a step forward.

See my recent post on the ODF converter:

http://www.itwriting.com/blog/?p=116

- it’s sloppy work in my view and needs fixing. But I do want this stuff to work.

> PS : I am independent vendor, a neutral party, and sell
> the most advanced third-party Excel 2007 generator out there at the moment.
> Believe it or not, I have been through EXACTLY what it takes
> to implement a part of the specs.

I believe you, and thanks for your comments.

Tim

It’s because you are a technical person, not a user.

Tell users why they should care about what you are talking about. If VBA macros are not supported, then the experience is bad. It’s like visiting a web 2.0 site with javascript disabled.

So either it’s in, and we have a competitive landscape, or it’s not. In the latter case, MS Office is the one and unique platform and the end of the story. If you admit that, what kind of value do you see in Ecma 376?

As for VBA being documented, it seems to me you confuse the VBA for Excel, VBA for Word and VBA for Powerpoint documentations which are part of the associated application installs, with the actual developer plumbing documentation. A documentation, currently privately owned by Microsoft alone (in fact, a spin off called Summit Software).

If you had read the specs in particular when it comes to VBA, you would have noticed that Microsoft introduced (without much fanfare) an additional set of constraints in order to bind the VBA macros to the actual document. This effectively makes the VBA macros dependent to any form of Load, Save and Run in any application that intends to preserve the file format.
This new attachment (see attribute CodeName in Ecma 376) is not described. In fact, in many places of the specs, the attribute is just described as a string with no explanation of the entire component life cycle that is serialized in it.

Those are facts.

PS : I am independent vendor, a neutral party, and sell the most advanced third-party Excel 2007 generator out there at the moment. Believe it or not, I have been through EXACTLY what it takes to implement a part of the specs.

Have you thought this through? First, a macro-supplemented document is an application, not just a document. Second, even if you fully documented VBA (which actually is pretty well documented, though not part of OOXML) it would not guarantee that you could implement a reader successfully. Reason: that macro could call the Windows API, or COM components: it is in effect open-ended. I think it is unreasonable to condemn the spec simply on the grounds that it does not cover VBA.

How is VBA “a simple example” by the way? I can’t think of anything like it, unless you mean the variants like Word Basic, non-VBA Excel macros etc. Similar reasoning would apply.

Tim

Really? Heard of VBA macros I guess. What’s a document value if you can’t instantiate it because you are using an application whose implementation is based on a paper which does not define VBA macros?

It so happens that many business word and excel documents use VBA macros.

I’m pretty sure you’d hate to take the responsability to put a product out there that would do just that. As it most certainly would fly back on your face quite rapidly. Deservedly so.

(and before you ask, VBA macros is a simple example. You need to bring the entire “legacy” documents are made of, a number of elements are simply not defined, specified or mentioned in the Ecma 376 paper).

The only one I can currently think of that might affect me regards whether the huge legacy store of information that my vast employer generates became inaccessible if we were to decide to change our office platform (which is highly unlikely). Where I work, there are several text-mining initiatives underway to extract and index the document store. Adoption of *any* XML standard would be a boon to such an initiative and this matters far more to us than whether we can adopt OpenOffice at some nebulously defined date in the future.

I’m sure that’s true if “fully” means implementing every last bit of legacy cruft.

However it should be feasible to write an app that generates valid OOXML and imports OOXML with graceful degradation.

Tim