The JTC1 Directives [pdf] are quite clear on this point. After a Ballot Resolution Meeting (BRM), if the text is approved, the edited, final version of the text is to be distributed to NB’s within 1 month. This requirement is in the Fast Track part of JTC1 Directives, specifically in 13.12:
13.12 The time period for post ballot activities by the respective responsible parties shall be as follows:
.
.
.
- In not more than one month after the ballot resolution group meeting the SC Secretariat shall distribute the final report of the meeting and final DIS text in case of acceptance.
The OOXML BRM ended on February 29th. One month after February 29th, if my course work in scientific computing does not fail me, is… let’s see, carry the 3, multiply, convert to sidereal time, account for proper nutation of the solar mean, subtract the perihelion distance at first point of Aries, OK. Got it. Simple. One month later is approximately March 29th +/- 3 days.
So the SC34 Secretariat should have distributed the “final DIS text” by March 29th, or at the very least, when the final ballot results on OOXML were known a few days later.
But that didn’t happen. Nothing. Silence. What is the hang up? I note that when NB’s said that the Fast Track schedule did not give sufficient time to review OOXML, the response from ISO/IEC was “There is nothing we can do. The Directives only permit 5 months”. And when NB’s protested at the arbitrary 5 day length of the OOXML BRM, the response was similarly dismissive. But when Microsoft needs more time to edit OOXML, well that appears to be something entirely different. “Directives, Schmerectives. You don’t worry yourself about no stinkin’ Directives. Take whatever time you need, Sir.”
It makes you wonder who ISO/IEC bureaucracy is working for? The rights and prerogatives of NB’s? Or of large corporations? Almost every decision they made in the OOXML processing was to the the detriment of NB prerogatives.
This delay has practical implications as well. Consider the following:
- We are currently approaching a two month period where NB’s can lodge an appeal against OOXML. Ordinarily, one of the grounds for appeal would be if the Project Editor did not faithfully carry out the editing instructions approved at the BRM. For example, if he failed to make approved changes, made changes that were not authorized, or introduced new errors when applying the approved changes. But with no final DIS text, the NB’s are unable to make any appeals on those grounds. By delaying the release of the final DIS text, JTC1 is preventing NB’s from exercising their rights.
- Law suits, such as the recent one in the UK, are alleging process irregularities, including (if I read it correctly) that BSI approved OOXML without seeing the final text. I imagine that having the final DIS text in hand and being able to point to particular flaws in that text that should have justified disapproval would bolster their case. But if JTC1 withholds the text, then they cannot make that point as effectively.
- There are obvious anti-competitive effects at play here. Microsoft has the final DIS version of the ISO/IEC 29500:2008 standard, and by JTC1 delaying release to NB’s, Microsoft is able to have 2+ extra months, free of competition, to produce a fix pack to bring their products in line with the final standard, while other competitors like Sun or Corel are left behind. So much for transparency. So much for open standards. How can this can considered open if some competitors are given a significant time and access advantage?
Note that I’m not talking about the publication of the IS here. I’m talking about the requirements of 13.12 and the release of the final DIS text. Obviously ITTF will have a lot of work to do prepping OOXML for publication. For ODF it took 6 months. For OOXML I would expect it to take at least that long. But that does not prevent adhearance to the Directives, in particular the requirement to distribute the final DIS text.
JTC1/SC34, noticing the delay in the release of this text, adopted the following Resolution at their Plenary in early April:
Resolution 8: Distribution of Final text of DIS 29500
SC 34 requests the ITTF and the SC34 secretariat to distribute the already received final text of DIS 29500 to the SC 34 members in accordance with JTC 1 directives section 13.12 as soon as possible, but not later than May 1st 2008. Access to this document is important for the success of various ISO/IEC 29500 maintenance activities.
This indicates that the final DIS text had already been received by SC34 (but not distributed) as of that date (April 9th).
Well, here we are, May 4th, over two months since the final DIS text was due, and past the date requested by the SC34 Plenary (who by they way have no authority to extend the deadline required by JTC1 Directives, but that is another story). We have nothing.
So, I’ll make my own personal appeal. JTC1 has the text. The Directives are clear. The delay is unnecessary and harmful in the ways I outlined above. Release the final DIS text now. Not next month. Not next week. Release it now.
After so many rules and/or guidelines that have been broken, distorted, etc., I do not believe they care about minor issues such as.. deadlines.
As the final draft has not been published according to the rules does that mean that the “standard” has failed? Please let it be so.
Actually I think your assumption that SC34 secretary really has the text might be a bit premature.
It is quite clear that the SC34 operates with the belief that the text are there, but are this based on fact or just a general belief that they must have the text by now?
My guess are that the SC34 secretary has recieved something, but sent it back to editor because there was to many obvious flaws.
For ISO to admit that the text is not in because the flaws are too great for the editor to deal with them in the given time would be fuel for the storm of attacks towards ISO. Their best option is try to pretend like nothing is wrong and hope everyone forget to watch when the information finally is leaked.
It is time to demand a independant investigation of how the ISO officials perform their duties. The best would be if OOXMLs ISO status is purged, but almost as good would be uncovering evidence that ISO officials biased the whole process .
BTW check out what Rick Relliffe and Alex Brown has been saying on Andy Updegrove’s blog…quite revealing to what kind of shell game they perform information wise
http://www.consortiuminfo.org/standardsblog/article.php?story=20080407120223550#comments
It is not my assumption that the text has already been submitted. I’m repeating the words of the SC34 Plenary resolution “the already received final text of DIS 29500”. Of course they could be wrong.
Or is the doubt that the text was submitted to the SC34 Secretariat in particular? That is the rule. See JTC1 Directives 13.9:
“…the Project Editor shall prepare the revised DIS (or DAM) and send it to the SC Secretariat who shall forward it to the ITTF for publication as an IS.”
I understood that you repeated the words from the SC34 Plenary resolution…but my doubts remain.
It would be very strange if the SC34 Plenary meeting was mistaken/missinformed, but what part of process so far has been sane or reasonable?
The question at this point are if ISO officials have given us reason to believe that they handled OOXML based on technical merit or if they are biased towards Microsoft.
Following the directives are rather essential to an organization like ISO, so what does failure to follow directives tell us?
The part of the JTC1 directive you specify does not mention who to distribute to.
You suggest it is to the NB’s but this is actually not correct because when that is the case the directives specifically mention distribution to the NB’s.
As in the above lines of the JTC1 directive 13.12 you actually skipped over.
So the distribution you mention is specifically from the SC secretariat to the ITTF after having recieved the revised draft from the projet editor.
This is also evident if you had read directive 13.9 “…the Project
Editor shall prepare the revised DIS (or DAM) and send it to the SC Secretariat who shall forward it to the ITTF for publication as an IS.”
If you read directive 13.9 and then directive 13.12 it is evident that the SC secretariat needs to forward the final revied draft to the ITTF no longer than a month after the BRM meeting.
And thus it does not state that to distribute the final draft text to the NB’s as you suggest.
So of course the SC34 secretariat has the final revised draft and has forwarded it to the ITTF for preparing it for publication.
@Anonymous – So the NBs voted on a spec that didn’t exist, and now the rest of the world is expected to conform to a specification for which there is no copy?
Wow. Just… wow.
Very few parts of the Directives say explicitly to whom to distribution is made. For example 13.2, says ITTF will “Distribute the text of the proposed standard or amendment as a DIS (or DAM)…”. That occurred at the start of the Fast Track process. But it is obvious from context that the document was to be distributed to all JTC1 members. You need to take it in context.
Also, there is a language nuance you might not feel, unless you are a native English speaker. When you give something to a single person or a single entity, you “send” or “submit” it. When you send to members of a group, you “distribute” it. The Directives are consistent in this. For example, 13.4 “shall send the SC Secretariat a copy of the DIS (or DAM)”, or 13.4 “ITTF shall prepare a proof of the IS and send this to the Project Editor”. But you won’t find “distribute” used with regard to ITTF or a single person.
Finally, with ODF (and note that Fast Track and PAS procedures are worded identically in this part of the process) the final DIS text of ODF was distributed to NB’s and a 30-day default ballot was held, allowing NB’s to file any objections to “the actions of the Project Editor in fulfilling the duties assigned for the disposition of the comments received.” So in that case, which is the last PAS or Fast Track that SC34 saw, the final DIS text indeed was distributed to NB’s.
Such is the joke that ISO and IEC make of “open standards”.
And note that nothing prevents Ecma from publishing their final text either. With ODF, we certainly published it at the OASIS site at the same time we sent the final edits to JTC1.
Process transparency, open participation, open communications, IP transparency, adherence to defined procedures, technical excellent. JTC1 needs to learn to lead, follow or get out of the way.
Process? For what?
The rubber stamps have been approved; the members can go on using and selling MS Office. Everyone’s happy. No need to inflict process on the status quo.
Why? To prevent JTC1 bureaucrats from taking us back to the stone age, that’s why.
I did post a long time ago, called “A Brief History of Open”
It contains reminders of history that we all already know, but maybe don’t appreciate enough. The Code of Hammurabi was a step forward because the Law was now fixed and public and people could know what it was. Magna Carta was important, because the will of a single person was no longer the solitary source and judge of the Law. And openess continues to move forward.
But if JTC1 wants to live by poorly written and largely unfollowed rules that are capriciously interpreted by anonymous bureaucrats, in unrecorded and unpublished pronouncements, then we might as well go back to the priests of Baal. Civilization obviously has not yet taken root in JTC1.
It is possible the delay is deliberate. The final copy may not be made available until just before the deadline for submitting objections. Then if anyone objects to any editing changes (that they did not reflect what was discussed at the BRM), then the ISO will simply say that the period for objection has passed and their hands are tied by the rules of procedure.
It might be a good idea if an NB were to submit a formal protest to the ISO and insist that the schedule for objection be extended by whatever period the release of the document has been delayed by.
Alternatively, if the document is delayed but the objection period is not extended, then some NBs may wish to state that they don’t recognise that copy as being legitimate and state that the meeting concluded with no output. There may be no rules which state this is an allowed position, but the current situation is outside the rules as well, so the ISO would be in a weak position to argue against it.
“BTW check out what Rick Relliffe and Alex Brown has been saying on Andy Updegrove’s blog…quite revealing to what kind of shell game they perform information wise
http://www.consortiuminfo.org/standardsblog/article.php?story=20080407120223550#comments“
A quick glance at Alex Brown’s comments show the hidden agenda he’s currently running here; he’s trying to suggest that OASIS is incapable of producing proper standards and that ODF should be given to SC34 to standardize, obviously so they can “merge” it with OOXML and produce a nice official standard only Microsoft can implement…
Quite frankly, I find it greatly humorous that he’s taking shots at the ODF spec without producing any evidence or facts or anything to show he’s even in the right neighborhood. And why is it so many OOXML supporters are now using the “ODF passed and it’s got problems, so it’s okay for OOXML to pass with the current problems” line? Even if ODF does have problems, odds are they aren’t as huge as the problems in OOXML, yet these morons seem to be ignoring that…
So in conclusion one can say:
– ODF was delivered in time
– OOXML is delayed
Now seeing the history of Microsoft and delays I am not really surprised.
Let’s hope the delay is shorter as the Vista delay was ;-)
My conclusion is quite simple. Ask yourself. Who can you trust more? The community or a company?
I know my answer …
@Anonymous:
The text of Resolution 8 from the SC34 Plemary meeting is also very clear about who to distribute to:
“SC 34 requests the ITTF and the SC34 secretariat to distribute the already received final text of DIS 29500 to the SC 34 members in accordance with JTC 1 directives section 13.12”
Note the reference to section 13.12 of the JTC 1 Directives just after “to distribute […] to the SC 34 members”. So obviously, Rob’s interpretation was shared with all the people who voted the resolution.
Haven’t anyone heard of Microsoft new calendar? For this year, the months March, April and may be May simply does not exists, i.e., totalDays(March|April|May, 2007) = 0 ;-)
Ecma General Assemblies will take place on 10-11 June in the US.
Is the approval of the new Ecma-376 version text on the agenda ?
I would think k that you as an IBM employee (IBM = member of Ecma International) could easily find out what is on the agenda for that meeting.
hAl, I have not seen the agenda for the Ecma General Assembly in June.
But note that Ecma rules require that proposals for approval as Ecma Standards must be submitted at least two months in advance of the General Assembly. So if they were voting on it on 11 June (the last day of their GA), then it would need to have been submitted to Ecma by April 11th.
Of course, if they send this for public review at the GA and neglected to have any public review of the new version, then it isn’t much of an open standard, is it?
But this is all hypothetical. I have no idea if this is up for a vote or not. I’m not exactly on Ecma’s Christmas card list.
Is there any possibility that the rules could be legally interpretable as requiring the revised text to be in the hands of the NBs before the vote can happen? I think it would be a good thing if it were possible to find a basis to argue that.
Ed, you need to put this in context of what is normal. In the typical ISO standard, average length less than 50 pages, a review and initial ballot will indicate a handful of issues which will be resolved by 8 people gathered around a conference table for an afternoon. Their agreement, in the form of editing instructions, will then be voted on.
At this scale, with a dozen changes to a 50 page specification, reading the editing instructions is sufficient. You can expect that a reasonably diligent voting member of ISO can figure out what the final text will be based on the editing instructions.
Now pump this up a few orders of magnitude. Say that you are dealing with a 6,000 page specification. And say that the initial review has found 3,500 errors (in some cases duplicates). And say that you have a meeting and the meeting comes up with over 1,000 changes to the standard, in the form of editing instructions.
What is a conscientious voting member of ISO to do with this? Certainly, in theory, they could manually apply all 1,000+ changes to the 6,000+ page standard and try to see whether new errors have been introduced, or whether conflicting requirements have been given. This is true, in theory, in the same way that they could move Mt. Fuji with a tablespoon.
But the net result is that, in effect everyone was voting blind on OOXML. This borders on professional malpractice for any engineer who assented to this.
So to answer your question, the rules were designed for much smaller standards. In such cases the editing instructions were sufficient materials for a reviewer. The rules did not anticipate the abuse these rules would be given, and ISO/IEC leadership did anything but lead to prevent the problems that have ensued.
Rob, it’s in some ways not a surprise that the person who expects to take a 6000 page OOXML document, convert it to .DOC, then convert it to an ODT, and then have it validate perfectly against a schema — would also expect that hundreds of people worldwide would have no problem taking that same 6000 page document, and apply over 1000 line edits to it, and be able to digest the results.
Somehow, those two expectations seem appropriate in combination. That’s a certain mode of thinking about how the world works.
It further seems no surprise that this same mode of thinking would lead one to think that Microsoft will ever permit changes to the specification that improve interoperability with their customers’ documents, or modify their software in such a way as to reliably conform to even the (non)existing strict specification.
Could one of the NB that voted NO
now file an appeal on the basis
that the DIS has errors.
(Final draft does not exist …
has not been distributed)
It wouldn’t even matter what they
pick as being in error. Without
access to the final draft, who could
prove them wrong?
(nsomos)
Would such an appeal be enough to
prevent OOXML from proceeding?
There are four types of errors:
1) Errors that existed in the standard from the start, were known, but which the BRM decided not to fix, based on Ecma’s recommendation.
2) Errors that were introduced into the text by the BRM by either approving defective changes proposed by Ecma, or by making their own defective changes. There were many of these, some quite embarrassing. But I can’t really give more details since there is no text I can point to.
3) Errors introduced by the Project Editor in the process of applying the editing instructions approved by the BRM.
4) Errors that were never noticed before in the standard and are just coming to light.
The general rule is errors of type 1 and 2 are not really good grounds for appeal. If a sufficient number of NB’s want to approve text written by 100 monkeys on 100 typewriters, they have that authority.
In case #3, how would you know unless you could review the final DIS text?
In the last case, error type #4, these are ordinarily handled during maintenance.
JTC1 Directives 11.1.2 defines causes for appeals of any action or inaction of a JTC1 or SC. Appeals must be by a P-member and be related to one of the following:
* violations of the directives
* the action or inaction is “not in the best interests of international trade and commerce, or such public factors as safety, health or environment”.
Additionally, decisions concerning DIS’s, like DIS 29500 can be appealed only if:
* “Questions of principle are involved”
* “The contents of a draft may be detrimental to the reputation of IEC or ISO”
* “The point giving rise to objection was not known to JTC 1 or SC during earlier discussions”
So I think there would be grounds for appeal, but the error would need to be in categories #3 or #4 (not known during earlier discussions) and would need to be severe enough to trigger concerns about international trade, public safety, reputation of ISO, etc.
I believe there is also clear grounds to appeal the inaction of the SC34 Secretariat in not distributing the final DIS text within one month of the BRM, as required.
Remember, appeals aren’t bad things. They are not personal attacks. They are not mean spirited. They are the only way we clarify exactly what the rules of JTC1 Fast Track are in a way that leaves a durable record that is a precedent for the next time this happens. Otherwise we just go around in circles, forever.
Ahahah! I’ve just found a very nice answer from Adobe related to the ISO PDF process, that I would like to share with the readers:
“Is Adobe doing anything to manipulate the ISO PDF process?
Adobe chose to work directly through ISO to create a true international standard. Adobe has not asked for any ISO process changes, nor does it expect to need any such changes. Adobe will work with the committees as the process goes forward, at the same levels as any other involved company.”
http://www.adobe.com/pdf/release_pdf_faq.html
To save some work, my answer for the you know who company:
“Is the you know who company doing anything to manipulate the ISO PDF process?
The you know who company chose to work directly for ISO to create a true international standard. The you know who company has asked for ISO process changes, and expects such changes. The you know who company will work with the committees as the process goes forward, at the same levels as any other business partner company involved.”
So, to recap, the OOXML should have been made available on March 29. (1 month after the BRM)
It is now 3 months late!!
Have you heard any further explanations for this delay?
Or any hint that it might actually be made available at some point?