On the scalability of a standard – time for a ‘Weirotron’
May 22, 2009
Apologies to my Business Intelligence readers, this post is pretty esoteric and refers to some strange goings on in the document standards world.
Apologies also to Rick Jelliffe, any resemblance to Schematron is entirely unintended.
After the drama of the initial Office 2007 SP2 ODF support was initiated by Rob Weir, related arguments spilled out all over the place. I got involved in a few places, but then left it alone whilst I got on with some productive work. There’s only so many ways you can say “it’s does not exist in the standard – admit it, fix it and move on”.
Needing something to accompany a coffee yesterday, I found that the argument was still raging on Alex Brown’s blog, so I settled down for some light entertainment.
Once again, Rob Weir was arguing with Alex about some interpretation of the ODF specification and calling Alex names. Then ‘Marbux’ weighed in with possibly the two longest comments in internet history.
This highly esoteric, intellectual argument between Dr. Alex Brown (the Convenor of ISO/IEC JTC1 SC34 Working Group 1), Mr. Robert Weir (the Chair of the ODF Technical Committee at OASIS) and Mr. Paul E. Merrell J.D. AKA ‘Marbux’ (a Juris Doctor) essentially (and I simplify enormously) about whether something specified in the schema as required for a document instance to be valid/conformant, was not actually required, because Rob said it wasn’t and Alex and Marbux said it was. Rob had his reasons for this, but they were completely lost on me. I mostly understood Alex’s reasoning, but all this came at the cost of a Red Bull chaser after the coffee.
Note: I was always under the impression that it was good practice for something that was invalid against the schema to be deemed non-conformant. Rob shows just what a absolute noob I am to assume that.
Here’s the selected highlights (I know it looks unexpurgated, but take my word for it)
“Alex, where do you read that validity of manifest.xml is required for conformance? That is news to me. Section 1.5 defines document conformance and says that conformance requires validity with respect to the OpenDocument schema. Section 1.4 defines that schema to be that described in chapters 1-16. This is confirmed in Appendix A. The optional packing format, including manifest.xml, is described in chapter 17, which the astute reader will observe is not between 1 and 16. Therefor it is not part of the OpenDocument schema to which validity is required for conformance.”
“Err, you’re reading the wrong version of the spec. The manifest invalidity problem only occurs for the two apps (OOo/Sun plugin) which claim to be using so-called "ODF 1.2"; so for the results here, the conformance section 1.5 of ODF 1.1, that you quote, is not relevant.”
“You misread the standard. But rather than admit and accept that, you are now trying to redeem your post by a back-up argument, which tries to apply your interpretation and prediction of what Part 3 of ODF 1.2 will say when it is eventually approved. But this text has not even reached Committee Draft stage in OASIS. It is merely an Editor’s Draft at this point. Are you really going to persist in making bold claims like this based on an Editor’s Draft, which has not been approved, or in fact even reviewed by the ODF TC, especially when contradicted by the actually approved ODF 1.0 (in ISO and OASIS versions) and ODF 1.1?”
“No, Rob – you are the one misrepresenting ODF.
The ODF 1.1 standard states: "[t]he normative XML Schema for OpenDocument Manifest files is embedded within this specification." (s17.7.1)
How is it anything other than non-conformant, for an XML document to be invalid to a normative schema?”
“Alex, as you know, normative clauses include those that state recommendations as well as requirements. So ‘shall’ is normative, but so is ‘should’ and so is ‘may’. Normative refers to all provisions, not merely requirements. Please refer to ISO Directives Part 2, definitions 3.8 and 3.12. So normative does not imply "required for conformance". The conformance clause defines conformance and that clause clearly defines it in terms of the schema excluding chapter 17.”
“I’m sorry, but you have veered off into the surreal now.
If you’re maintaining that "the normative XML Schema for OpenDocument Manifest files" is in fact NOT REALLY "the normative XML Schema for OpenDocument Manifest files", then we’re going to have to disagree.”
“Alex, read more carefully. I never said that schema was not normative. What I said is that "normative" is not the same as "required for conformance", as you had been asserting. But now I think you may be confused on this as well.”
Joe Sixpack Developer Trying To Implement ODF:
“WTF!!! This is completely crazy – it would be easier and quicker to send someone round to every user’s desk and type it out in the app of their choice instead”
This reveals a real practical problem, should I wish to implement ODF. I would need to consult the Oracle of Westford (Rob Weir) about every detail of the entire implementation, in order to be on fully safe ground.
Now if Alex Brown and various other highly qualified commenters can misread the ODF specification so heinously, needing the expert advice from the ODF Technical Committee Chair himself to put them right, what chance do lowly developers have?
It appears from this there is no chance that any developer will be able to interpret the specification properly, since only Rob Weir (and perhaps the folks working on OpenOffice) has the intellectual capacity to navigate this ball of semantic string.
Having to cross-reference this file format equivalent of the newest, most advanced physics paper on the planet every time you write a line of code is going to lead to madness.
This leads to a huge scalability problem, with developers worldwide having to get an opinion from Rob Weir on every implementation detail – although he could save a few hours a day by giving up the blog posts and comments, it would not be anywhere near enough to cope with the deluge of requests.
So, the solution to this is clear – we need to implement Rob Weir as a web service, a Weirotron if you like. That way, everyone can query the Weirotron and get back the definitive answer to any ODF question, without having to deal with the obviously labyrinthine spec that has bamboozled so many leading XML experts.
In addition, the Weirotron could help solve those pesky interoperability issues that stem from some areas that ODF relies on the OpenOffice source code for, like Formulas, and areas where the spec is a bit light, so to speak, like Change Tracking etc. I’m sure that this would really assist Microsoft and many other struggling developers in implementing support for ODF (or rather the Weir-approved cod-ODF) correctly, with the inherent blessing of the ODF TC Chair.