OOXML: Join in the Bug hunt
Let’s join in the bug hunt [Updated: See below]
Rob Weir has produced another little gem of an analysis: to do a reasonably scientific search for errors and bugs in the OOXML specification. The idea is to see just how many errors were really caught in the original 5 month review process for the 6045 page specification, and how effective the BRM, held in Geneva a couple of weeks ago, was at fixing them.
His initial findings do not make very comforting reading…
… I’m not done with this study yet. I’m finding so many defects that recording them is slowing me down considerably. But since this is topical, I will list what I have found so far, based on the first 25 random pages, or 1/8th completion of my target 200. I’ve found 64 technical flaws. None of the 64 flaws were addressed by the BRM. Among the defects are some rather serious ones such as:
- storage of plain text passwords in database connection strings
- Undefined mappings between CSS and DrawingML
- Errors in XML Schema definitions
- Dependencies of proprietary Microsoft Internet Explorer features
- Spreadsheet functions that break with non-Latin characters
- Dependencies on Microsoft OLE method calls
- Numerous undefined terms and features
… this doesn’t look good, does it? Not only am I finding numerous errors, these errors appear to be new ones, ones not detected by the NB 5-month review, and as such were not addressed in Geneva. Since I have not come across any error that actually was fixed at the BRM, the current estimate of the defect removal effectiveness of the Fast Track process is < 1/64 or 1.5%. That is the upper bounds. Of course, this value will need to be adjusted as my study continues. However, it is starting to look like the Fast Track review was very shallow and detected only a small percentage of the errors in the DIS.
If you fancy helping Rob and the rest of the free world, he lists the page numbers (chosen at random) from part 4 of DIS29500 that should be examined in detail for errors and such like. Here’s just a few of the page numbers (out of 200) to check:
… 1102, 1611, 3016, 2646, 3083, 5105, 747, 1142, 2596, 845, 626, 4047, 1415, 5143, 3997
The fact that in examining just the first few pages he finds numerous NEW errors indicates yet again, that this specification should never have been Fast Tracked in the first place and is just simply not in a fit state to be declared an ISO standard.
It really does make me wonder how certain National Bodies can be even remotely sincere when they decide to approve such a badly written specification.
[Update: In the few scant hours since Rob’s article was originally published, go and check the comments section! Even if you aren’t a software engineer, the errors and inconsistencies being reported are simply mind boggling. How on earth can this specification be approved as an international standard when it is just so bad?]