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?

“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.”

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.

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?

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.

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.

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.

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.

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.

- 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 …

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…

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.

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.

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.

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.

Wow. Just… wow.

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.

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?