Always be careful what you wish for. I liked Stuart Okin when he was chief security officer for Microsoft UK and thought he did a lot for Microsoft's credibility in this area, but I'm afraid I occasionally laughed at Microsoft for putting a developer type in charge of security, instead of a superannuated spook as everyone else …
Architecture is Important
"The great thing about Standards is that there are so many of them."
The good and bad news all in one sentence. But Architecture is the real issue here, and it too suffers the problem of standards.
Architecture may be more important than standards. It sets the playing field for a set of applications that (are supposed to) accomplish a specific set of purposes. But the conflict in architecture design arrives when the desire for clear limits to the design space confronts the need for future flexability. Often times the future flexability wins out and the architecture becomes ill defined and less than useful.
This is a bad approach 90% of the time. The key to clean application design and implementation is a clear set of limits, not something that looks like an amoeba.
The best way I have to convey my view of how this should be done is to list the best and worst ways to design:
1. The all inclusive design: Design is finished when you can no longer add any features, AKA 'Kitchen Sink' design.
2. The exclusive design: Design is done when you can no longer take anything away, AKA the Einstein design criterion.
Note that #1 is Microsoft's design philosophy, and it gives us products like Word, which will do almost anything you want after a few years of training and experience. My personal selection, having tried both when I was younger, is #2.
Architecture defines the playing field for systems, and it should follow the principle in #2 for almost all systems. It is only where systems are probing the boundaries, experimenting with approaches, that approach #1 is useful, and even there well defined boundaries should exist if only to limit the time spent in marginal areas.
In both cases, experience and critical analysis of the purpose for the system should be your ultimate guide. The closer you can come to a limited, well defined playing field, #2, the more stable and reliable will be the product.
why not ooxml ?
regarding that last paragraph... a nice collection of resources is here.
especially see item #2. enlightening :)
Why not OOXML - well it's a horrid name...
Very misleading name, potentially. I must say I share your concerns about Open XML, especially if it is some 6000 pages. And some of the issues with date formats and country codes in the references you cite horrify me - as an ex DBA/data analyst, I see tears before bedtime if people actually try to use this "standard", especially in a non-MS environment.
But I haven't read and analysed the whole 6000 pages - I do wonder if all the people I saw filling the Microsoft petition have.
What I have done, is to commission an article from somebody competent, looking at this issue dispassionately....