These whispers tell Rob There is an interesting disinformation campaign being waged against ODF. I don't want to deal with his points in detail here, Madame Arcati probably being a more suitable person for the job, apart from to say that complaining about FUD in a blog that uses allegedly secret documents and a made-up kind-of quote to allege a conspiracy is a bit...well...interesting. (And, as I pointed out for an incident by an IBM colleague, isn't making up statements and attributing them to rivals against IBM's Code of Ethics?)
Instead I want to briefly make a few points about comments that have made by Groklaw readers and Slashdotters: the Chinese whisperers in the echo chamber.
This is a good example:
Alex Brown and Rick Jelliffe are also by far the most prolific posters in the feedback for OASIS Open Document Format for Office Applications (OpenDocument) TC mailing list email@example.com. They seem to be trying to flood out comments by others on the mailing lists.
The sheer volume of posts these two put out would indicate that they aren't authoring these posts themselves, but rather there must be a large FUD team operating (presumably run by Microsoft) that produces the comments which are then channeled through the two.
This was too much even for Rob, who wrote:
For the record, I encourage people to post defect reports and proposals to the OASIS ODF TC's comment list. That is what it is there for. Some of the extraneous discussion that pops up occasionally is out of place, but for submitting defect reports, that is the place to do it. In fact, I particularly welcome criticism from ODF's most vocal critics. That's how we make it a stronger standard. Think of it like bug reports for a product. The bug reports don't create the bug. They just report it, and give you the opportunity to fix it.
So, although I think these same parties spout off a lot of FUD on their personal blogs, I would not fault them for reporting issues on the office-comment list.That is what the list is there for.
Remember, we still have not seen the public comments received on OOXML during its Ecma review. Not even Ecma members have been allowed to see it. My guess is there were very few comments received. So it is one of the major qualities of ODF as an open standard that our comment list is open for anyone to post to, and for anyone to read. This is a good thing.
Anyone interested should just look at the postings by Alex and me on the ODF TC comments list, which are supposed to be work of this large FUD team. Alex is systematically reviewing ODF, which is a duty from his British committee work, and is what happens when something becomes an international standard. I have raised several issues for ODF-NG and contributed to some discussion threads.
The things to realize is
- this comments list is the forum designated by OASIS and the ODF TC by which ISO SC34 committee members should contribute;
- the ODF TC has decided that the way it wants the maintenance of ODF to go is that problems get fixed in the next version, so the appropriate place to report problems in ODF 1.0 or ODF 1.1 or the draft of ODF 1.2 is for SC34 committee members to submit them as comments to this list;
- maintenance is very important at ISO: only dead standards are perfect, so reporting and negotiating problems is not something nasty, it is the core business of a standards committee member;
- the ODF TC is not open to
commentsabout drafts from the outside world during the early stages : if you want to contribute () you have to pay your money and join up (). () At a certain stage, when the TC is happy with it, a draft will be released for public comments. So it turns out not to be the appropriate forum for raising those kinds of comments yet. (I have refrained from a systematic review of ODF 1.2, though I have more than flicked through the draft, to respect this schedule: trying to catch up with WG4, the SC34 OOXML working group, takes more of my time at the moment.) On the other hand, because it is a public forum, if a topic has been raised by someone, basic openness dictates that people can weigh in, if they have something technical to contribute. (Actually, when I find a little problem in the draft of ODF 1.2 that gets under my skin, I usually email a committee person.
- During April and May, that list also had another function, in that it was used to gather requirements for ODF-Next Gen. As far as I can tell, I certainly was the largest poster to this: however, I note that some of my comments were also echoed by the SVG working group and by a Chinese vendor. (That there were so few other responses shows a deplorable passivity by the ODF-using population, I am afraid to say: a thing which previously I had thought was a characteristic of disenfranchised Microsoft users.)
So here is an example of what Alex (the supposed rabid anti-ODF pro-OOXML apologist) writes:
Well, the feature's in a bit of a mess in OOXML because of a (possibly competing) concept of "conformance class" that applies to the "strict" and "transitional" versions of OOXML.
Still, that's an opportunity for ODF to do better :-)
The problem you've still got in 1.2 is that is permissible for an implementation to omit any feature and yet still be 100% conformant. So (to take a hot-button example from the BRM) if a vendor decides to leave out accessibility features, then by the letter of the standard, that's still fine conformant behaviour.
And here is an example of me:
...So my proposal is that all document constraints (other than those that can be expressed simply in the RELAX NG schema or which require complex parsing) should be expressed in a normative Schematron schema. The schema should be processed so that the plain language assertions are made into numbered lists, and these put (informatively) in the conformance section of the ODF standard.Regular readers will recall that this is the direction that the HTML5 specification has been going.
Getting adequate conformance is hard. It is in the interest of vendors to be flexible in areas which may not serve the public interest: it is natural that they want the standard to reflect their capabilities and druthers. But apart from balancing interests, documents standards have a very difficult time in specifying conformance tightly. To see Alex and my comments as part of some denial of service attack on ODF is laughable; indeed to see the volume of what we write as a sign that there must be some large team behind us (or even that we are in some way co-ordinated) is I suppose something we should take as a compliment.
So I ask readers, even those who Rob Weir wants us to call tin foil hat brigade (and here), to make a decent review of ODF 1.2 when the draft comes out for public comment. Just take one section, where you know a bit about the subject matter, and if you find some decent improvement, think of a fix and suggest it.
It would be great if the ODF 1.2 review was even 10% as thorough as the OOXML review was. OOXML had between 1000 and 6000 people participate in the review, as far as I can see. So getting a few hundred people in serious, but friendly, review of ODF would seem reasonable.
I would also issue a challenge to the FOSS people who spent so much energy complaining about DIS29500 only to find that, miracle of miracles and horror of horrors, many of their complaints were taken on board to improve DIS29500 (and continue to be taken on board): For every hour you have spent on OOXML review, spend an hour on ODF review. Join the conspiracy!
[UPDATE] For the word from OASIS on what the purpose of the ODF comments list is, see this message
... this list is intended to be "input only" - that is, one should not expect discussion from TC members on any of the posts on this list. The intent is that the posts would be discussed by the TC which would then decide what action, if any, to take. If individuals want to take an active role in the development of the spec, they should then join the technical committee itself.
I would like to make it clear to everyone commenting that the TC has not yet approved a formal 60-day Public Review of the specification; the approximate date posted in the call for requirements for "ODF-Next" was late April. At that point in time the TC will be required to log all comments received along with their resolution before proceeding to the next approval level. That said, OASIS encourages feedback at any stage of a specification's lifecycle; early feedback is typically much easier to react to than that provided late in the game.