The idea was to make the C++ programming language work better in Microsoft’s .NET framework. It started off as the Managed Extensions for C++, first available in 2000, and later in Visual Studio .NET 2003. Managed Extensions were reformulated in Visual Studio 2005 where they were called C++/CLI, referring to the Common Language Infrastructure, the runtime abstraction in .NET.
CLI itself had earlier been standardized in Ecma (approved in 2000) and Fast Tracked through ISO (approved in 2001). So, it was not much of a surprise when the C++ variant for Microsoft’s .NET Framework, C++/CLI, was proposed for standardization as well. Ecma TC39/TG5 started work on C++/CLI in December 2003 and Ecma approved the specification as Ecma-372 in December 2005. Two years in committee, resulting in a 304-page specification. This used to be considered a fast pace.
After approval by Ecma, C++/CLI was submitted for Fast Track processing to ISO/IEC JTC1/SC22 as DIS 26926. Like any other Fast Track in JTC1, this process started with a 30-day contradiction period. Contradiction submissions were made by both Germany[pdf] and the UK[pdf].
The UK’s position was that calling the standard “C++/CLI” would cause, and in fact was already causing, confusion among users with the already existing C++ programming language. The name of the standard was unacceptable:
We consider that C++/CLI is a new language with idioms and usage distinct from C++. Confusion between C++ and C++/CLI is already occurring and is damaging to both vendors and consumers.
A new language needs a new name. We therefore request that Ecma withdraw this document from fast-track voting and if they must re-submit it, do so under a name which will not conflict with Standard C++.
Similar views were expressed by Germany:
With reference to §13.4 of the JTC1 Directives, 4th edition, DIN brings to the attention of the JTC1 secretariat that we perceive a contradiction between document JTC 1 N 8037 “30 Day Review for Fast Track Ballot ECMA-372 1st edition C++/CLI Language Specification”and the JTC1/C++ standard ISO/IEC 14882:2004 “Programming language C++” and related technical reports.
We propose that the document is input into SC22 as a regular New Work Item Proposal and assigned to WG21 for further processing.
Ecma responded[pdf] to these objections in a 5-page letter, on 29 January 2006, that refused to make even the most basic concession, such as changing the name to remove the C++ reference.
So the objections are ignored, and they move on to the 5-month ballot period, starting March 9th, 2006. When the ballot closed in August, and the votes were counted, C++/CLI had received 11 out of 20 P-Member votes (55%) and a total of 9 negative votes out of 26 total votes cast, or 34.61%. So it failed both to get the required 2/3 approval of P-Members, as well as to keep the negative votes to less than 25%.
Germany and the UK voted disapproval. No surprise there, since they had objected early in the process, and their objections were ignored. In fact one of Germany’s comments in the ballot was:
DIN has commented before, as well as BSI did, that allowing fast-track standardization of the “C++/CLI Language” under this name clearly conflicts with an existing and actively maintained standard: ISO 14882 – the C++ Programming Language. The document under review spells out under “NOTE FROM ITTF”, bullet 2.2, that ITTF will ascertain that this proposed standard does not conflict with any other International Standard but such a conflict was pointed out. No reason has been given why this objection was overridden. Thus, DIN wants to express its surprise that standardization of this proposal went forward.
The US comments included:
The proposed standard is not market driven, nor is it the product of an industry consensus.
We are unimpressed with the very low level of C++ community participation mustered in the design and refinement of the current document, and feel, quite frankly, that the current state of this document is not at a high enough level of technical excellence to merit the ISO imprimatur.
France said:
This document should be withdrawn from the fasttrack approval process pending re-drafting and a more adequate review prior to voting. Better yet, retain it as an Ecma standard only until a clear market consensus develops that a JTC1 standard in this area is needed.
And so on, down the list.
It should be noted that a failing vote in the 5-month ballot is not necessarily fatal. The Fast Track submitter, in this case Ecma, can call on the SC Secretariat to convene a Ballot Resolution Meeting (BRM), where the issues can be discussed and resolved, possibly leading to a positive vote after a further ballot. This is Ecma’s right as a Fast Track submitter. However, C++/CLI did not see a ballot resolution meeting. The JTC1 Secretariat recently notified SC22 members:
We have been advised that the comments accompanying the Fast Track ballot for DIS 26926 are not resolvable and that holding a Ballot Resolution Meeting (BRM) would not be productive or result in a document that would be acceptable to the JTC 1 National Bodies. Therefore, our proposal is to not hold the BRM and to cancel the project.
So, the BRM which had been scheduled for April, 2007 has been canceled, and that’s where it stands today, with the attempted Fast Track of C++/CLI dead from seemingly easily preventable flaws.
Lessons, anyone?
Don’t ignore NB members. If they take the time and make the effort to point out your flaws early in the process, then you should count yourself lucky. This is like the school teacher walking around the classroom during a quiz and pointing to one of your answers and saying, “You might want to take another look at that problem”. If you ignore her advice and just turn in your paper, then you deserve the grade you get.
It is instructive as well that although only two NB’s objected in the C++/CLI contradiction period, this grew to a far larger number by the time the 5-month ballot had ended. Ignoring problems doesn’t make them go away.
One last thing. Any guesses on how long those contradiction arguments stay online before they are taken down to preserve the shrouded secrecy of ISO process? I advise you to make a copy now. I certainly have.
I should note that the composition of Congress has changed. I expect to see some legislative proposals to ensure ANSI (as the representative for NIST on ISO) considers the needs and concerns of end-users and not just vendors in national and international standards.
Until recently, the desires of corporations to increase profits, even at the expense of consumers, was ignored by the federal government. Witness the fame that the NY Attorney General got by doing the SEC’s work for them. With the changes in Congress, agencies from the FCC to the DOJ are facing increased scrutiny of their activities. I do not believe NIST or ANSI (as the designated proxy for NIST in ISO) will be exempt from this.
The only question is whether this occurs before the next stage at ISO. That is, will this be in front of “net neutrality” or after it?
Rob, you make a good point about the consequence of ignoring the National Bodies. Discarding their very serious work (think how difficult and painstaking it is to beta test software properly) will encourage more disfavor toward Microsoft’s Ecma 376. I’m no genius, but isn’t there anyone at Microsoft who might give pause to their endless shoot-self-in-foot actions? As you imply, your critics are often your greatest teachers. If I were in the MS-OOXML room when they decided to fast-track it through Ecma, I hope I would have had the wisdom of your teacher-student anecdote, and asked if repeating the same behavior that failed us in 2006 would be wise in 2007.
Microsoft’s built-in advantage for their software and file formats was their natural distribution channel via their OS. ISO certification of ODF was a spike strip in the road for MS Office, and it’s surprising Microsoft decided (once again) they would choose to reinvent the wheel rather than using the standard round form of the current wheel. We all know why they do it, but not why they keep doing it, when a few actions would bring them long-term good will. They may remove the contradictions and objections, but thank Zeus for GrokLaw’s EOOXML Objections page.
Someone suggested that MS will plant their employees in all the voting committees. That way no consensus can be reached.
So voting will partially be done by people who will be sacked if they vote against MS’ wishes. If you don’t believe this, think about what happened to Peter Quinn who opposed MSOOXML, and didn’t even work for MS.
Winter
I wonder if those objections are the REAL reason that C++/CLI failed.
C++/CLI is not any more confusing than C++ and C is. Would it be better if Microsoft did the same thing the C++ namers did, and rechristened C++/CLI C++++?
Or let’s put it another way: FORTRAN and COBOL have multiple, incompatible versions: FORTRAN/77, 90, 95, 2003 and COBOL-68, 74, and 2002. How isn’t that as confusing as C++/CLI? Yet these are standards!
Hi Lizzie,
I think the point is that when you already have a C++ standard and an ISO working group actively maintaining and evolving that standard (such as their ongoing work on C++0x), then you probably don’t want someone forking off another incompatible standard and using the C++ name. That is the confusion.
This is different than evolution within a standard, where C++ 2.0 (1990) evolves into ISO C++ (1998) then revised as ISO C++ (2003). It is good to have competing ideas and visions, but it is much better for the consumer when these ideas fight each other out within a technical committee, rather than have the battle leak into the marketplace, where consumers are hurt by conflicting and incompatible standards, e.g.,the whole Betamax versus VHS debacle.
But that said, I can’t read the minds of NB members to divine the “real reason” if there are any beyond the above, why C++/CLI failed.
Anonymous,
I certainly have personally observed an increase in Microsoft participation in JTC1. For example, in the US our SC34 recommendations are made by a committee called INCITS V1, of which I am a member, the only member from IBM. Last year we had a single Microsoft member as well. But now we have three Microsoft members.
Zridling,
They seem to have turned this into an adversarial process, where the NB must be defeated or overcome in order to make OOXML an ISO Standard. This is exactly the wrong thing to do. Declaring victory because you were able to ignore and bypass objections from NB’s? That’s crazy.
Success comes from listening to criticism and then taking that feedback to make a better standard, and then earning NB and respect by your responsiveness. If I may brag a little, I think the way that the OASIS ODF TC handled the accessibility concerns raised in Massachusetts should be a model for how to handle criticism of a standard. We didn’t push the critics away. We brought them into the process, asked them to help us solve the problem, and turned their recommendations into a revised standard.
Hi Walt,
You raise some good points. I think we are at the turning point for technology standards. In the past, when standards were developed for things like Ethernet, or FORTRAN, the average consumer didn’t care. These standards did not touch their lives.
But now, the things that are being standardized are the things that will directly effect what we as individuals can do with the digital lives we all now have. Standards related to DRM, encryption, spam, media formats, document formats, etc., should be of interest to consumer organizations, policy makers, politicians and end users. I think that some standards organizations, like ISO, are slow to recognize the change. The standards are no longer for technology that is deep within the back server room, unseen, unheard. The technology is now on the desktop, in the living room, in the car, used by school kids and grandparents, in all languages, across the globe and instantly. These standards are important.
Thanks for the insight, Rob. It’s nice to hear an inside voice on what’s going on here, because those of us on the outside wouldn’t have any clue what’s going on if not for you.
But, umm, is it a bad thing that I memorized the URL for this blog as Rob Weird minus a D? :-) Sorry! And good luck with that barleywine, BTW.
a little off topic… during this 6+ months process ( ISO discussion about fast-tracking OOXML ), i hope ODF advance this important issue, adressed during the Berlin-28th-February-2007-IDABC-German- Presidency’s workshop on Open Document Exchange Formats [1]:
“
Results about the study of Open Document exchange formats:
Conformance testing and document validation possibilities
*are needed* -> in order to facilitate mapping / conversion;
“
[1] http://www.openforumeurope.org/index.php?option=com_content&task=view&id=937&Itemid=1
sorry, the correct link:
http://www.openforumeurope.org/index.php?option=com_content&task=view&id=937&Itemid=1
I hardly think it is likely that Microsoft will ever outnumber all it’s competitors and supporters of the OSS community in the national bodies associated with ISO.
Winters suggestion that MS employees could influence the ISO committee seem therefor very far fetched. If anything it could be the other way.
Rob, looking at the strong wording you cite about the c++/CLI reactions by the national bodies, I think, looking at what is published about the NB reactions about OOXML, they seem a lot less strong in their wording this time showing already a distinctive difference in attitude about the possible standard.
Hi Wraith,
I don’t think it is necessary for Microsoft to get an outright majority in an NB to influence the vote. It is more complex than that. Most NB’s work on some sort of consensus voting procedure, where 2/3 or maybe even a 90% vote is required to recommend a position. Increasing Microsoft’s participation in a NB could possibly turn a “No” vote into an “Abstain” by preventing a consensus, even if a clear majority supported a “No” vote. That is my understanding of what happened in several NB’s during the contradiction period.
Of course, this works both ways. Lack of consensus can prevent a majority supporting OOXML from registering a “Yes” vote, and instead abstaining. But every NB that abstains increases the chance of OOXML failing for lacking a 50% participation rate among JTC1 P-Members. So you really need to persuade your opponents to agree with you, not just deadlock them and force them to abstain.
So I think that this will end up like this: NB’s without a consensus will abstain, and only those P-Members with strong (> 2/3) opinions one way or the other will cast votes. That is why I see OOXML’s odds as very slim at this point.
To win they need:
1) 50% or more of P-Members must vote. So if too many abstain for lack of consensus, then OOXML fails.
2) 2/3 of voting P-Members(those who did not abstain) must vote “Yes”. As mentioned earlier, this often requires a 2/3 consensus in the individual NB’s.
3) No more than 25% of all votes cast can be negative. This includes possible votes from the entire community of 150 or so ISO nations. Note that no number of “Yes” votes from the general membership can cause OOXML to pass. Only the P-Member vote can pass the ballot. But the general membership has effective veto power over the P-Members if a sufficient number of the general membership votes against OOXML.
I’m not saying it is impossible for OOXML to pass. But when I look at the numbers, and look at the lack of enthusiasm for this standard, as indicated by the NB contradiction arguments, and look at recent history, then I am unable to find a winning play for Microsoft here. Although they can increase participation in NB’s, I think that only helps them get abstains, but that is a double-edged sword because of the 50% participation requirement.
I’d be interesting to hear if anyone sees this in a more optimistic way. What reasonable prospects do they have of getting a consensus “Yes” vote out of 2/3 of JTC1 P-Members?
It think many of the issues raised by the natinal bodies were marginal at best. The Ecma answer should satisfy at least ten to 14 of the reacting national bodies as frankly they did not really raise any kind of serious issue. There is about 5-7 of the national that seem moderatly negative but even those countries could be persuaded as I do not think that the national bodies have done much research yet. It seems mostly they copied a lot of the raised issues from here or Groklaw.
I can’t say I was impressed by the quality of the National bodies responses (to put it mildly).
I think the national bodies should probably look at the specs a bit better and also verify the answers given by Ecma with serious experts.
I can see only some of the issues raised by you and others stay on the table. These however might not be considered important enough to raise issue with the format as a whole. Also I think Ecma can if needed show some commitment in improving areas that might worry the ISO national bodies. Ecma could promise a 1.1 version before the end of the year to address left over issues. That would be simular to ODF addressing several issues in it’s spec after standardization.
Things I think can improve is deprecating the leftover bitmasks and removing VML from the spec. Also improving certain explanations for deprecated features in section 2.15 and mayby state that on those elements for full confomance it is enough to inform the consumer that original rendering might not be available.
“It think many of the issues raised by the natinal bodies were marginal at best.”
ECMA rejected each and every comment. The overlap with ODF and the uncertainties about the IP are already each reasons to reject ECMA376. ISO guidelines specifically state that ALL known patents relevant to a standard should be disclosed. MS have disclosed NO patents at all (at least not publically). But MS have always insisted that there are such patents (but they might not sue, maybe, see the
Open Malaysia blog, MS’ legal councel couldn’t tell)
Especially the refusal to do anything about the Excel date horror is a howler. If MS would just say to switch to a Julian day calendar and add a conversion in Office 2007, they would have shown the world that they want to listen, without any fundamental changes.
Insisting on limiting spreadsheet dates to post 1899 AND standardizing an incorrect day count + two other date formats (post 1904 and the Word format) is such an easy target.
But I remember that you had a VERY long argument on Groklaw about this.
(see
EOXML unanswered questions thread, you are hAl, aren’t you?). You admitted to not being a programmer, however you ignored every counter-argument brought forward by people who DID have experience in programming.
Also, saying that the world lobbies for ODF and MS for ECMA376 should make you realize how the world views ODF vs. ECMA376. Or not? Or has the world a duty to give MS their own standard?
Winter
Preceding anonymous:
Contrary to what you imply, “[i]nsisting on limiting spreadsheet dates to post 1899” or some other recent date is not grounds for objection. It is NECESSARY.
Why? Because the human calendar itself is full of workarounds bizarre tinkering, including:
– leap years
– leap seconds
– daylight savings time (which varies according to locality and year)
– missing days; see http://www.genealogytoday.com/columns/everyday/030902.html and http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates
I wonder whether it would work better to just have a workbook level setting for dateOrigin. It can be 1904 for Excel files created on the Mac and 1900 for Excel files created on Windows, and it can be set to other values by other vendors according to their needs. All dates serial numbers are offsets from the declared dateOrigin.
Also, have a do1900LikeExcel setting, similar to the other backwards compatibility options OOXML has. Set it to true for spreadsheets which are converted to OOXML from legacy XSL files. Microsoft could continue to set it to true for new Excel documents as well if they wanted. But other implementations could set it to false.
Although I think it is bad practice to load up a standard with backwards compatibility options that consider a single vendor’s needs only (what if 1-2-3 or Quattro Pro have other backwards compatibility needs?), it is a further insult to require that other vendors adopt the same bugs that Excel has.
Let Excel do what Excel needs to do, but also let other vendors do it right. Welcome to the 16th Century, Microsoft. We calculate leap years differently now.
For the date thing Ecma could probably better have created an alternative in making the 1904 format leading and the 1900 format with the leap year issue as deprecated.
However I still would like to see how ODF is going to handle ISO dates in spreadsheet formulas. Things like timezones and duration which make ISO dates different from a numerical date format are not commenly used in spreadsheets nowadays and I wonder how that will work out in it’s implementations. That is not straightforward.
The Wraith said:
“I do not think that the national bodies have done much research yet. It seems mostly they copied a lot of the raised issues from here or Groklaw.”
Well, there are at least three counter-points to that, so I don’t think it makes the case you want it to:
A) That means this shouldn’t even be on the fast-track to begin with because no one could properly review a 6,000 page standard in that amount of time.
B) Even with limited amounts of time, they all came up with many of the same obvious objections. Contrary to what you say, I sincerely doubt they’re copying things from here or Groklaw. Rather, it speaks volumes if that many people in that little time all agree that a few specific issues are real problems.
C) Now suppose they _did_ copy the objections from Groklaw or another source (I don’t buy that, but just for the sake of argument). If they copied it, they agreed that it was, in fact, a problem. Otherwise, why object? Microsoft has a lot to lose here, but what do these bureaucrats have to gain, exactly? Do you picture them saying “Yay! We just pissed off Microsoft! I bet that’ll go over great during our next BSA licensing audit!” or what?
Wraith, what can I say? The year 1900 was not a leap year. It is that straightforward. February 29th did not happen. People went to bed on the 28th and woke up and it was March 1st.
There are people who believe that crop circles are messages from aliens, that the earth is flat and that man never landed on the moon. But I have never heard even the most deluded person maintain that the year 1900 was a leap year.
Microsoft can get this right in their product while preserving interoperability with legacy documents. I and others have given several ways in which this could be done. They have smart engineers. I’m sure they can think of other ways of getting this right as well. Will it required writing some code? Yes. Will it take some processor cycles. Yes, probably an “if” statement. But compared to all the code and CPU cycles Microsoft has wasted giving us eye candy like the translucent 3D windows in Vista, this will be minuscule.
But instead of working on a solution they expect everyone else in the world to adapt their code to Excel’s bug.
I agree with Rob that a special setting for the leap year would have been a good choice. It would have been usable for all converted .doc files.
But I guess it might still come to some solution on that particular point because it seems fairly easy if that issue were the big hurdle for ISO at the end of the Fasttrack process to then have Ecma alter the date issue in an amendment or in a future version and make this leap year format obsolete from then on.
These (minor) issues are all resolvable if needed.
The only real issue that might stay is whether ISO should standardize this format next to the OpenDocument format. I think they should approve the OOXML format because OOXML supports a different need than ODF. A different market requirement as Rick Jelliffe calls it.
I think there is room for two formats. ODF still has a lot to prove. That is not a format for now but mayby for the future. For now the market would like compatibility an reliability which just seems more likely to come from OOXML with it’s likely huge marketbase.
“I think they should approve the OOXML format because OOXML supports a different need than ODF. “
What need especially? A format for new Office documents, but thats ODF too. A conversion format for legacy documents, but ACME376 can do that all 100%, round trip.
Can OOXML2007 do 100% round trip fidelity with older formats? Difficult to say, as OOXML leaves crucial information unspecified. Can anyone outside MS do 100% round trip fidelity between older Office documents and OOXML. Certainly NOT.
But this last fact is the real point. OOXML is MS’ format, and MS alone can really use it.
“I think there is room for two formats. ODF still has a lot to prove.”
Like in Austria, where they experimented during the war with driving simultaneously on the left side of the road (Austrian civilians) and on the right side of the road (German tanks). Free choice of standards indeed.
And ODF should prove what? That it is usable and has real world applications?
OOXML should first prove that it can be implemented at all, instead of evolving once out of a gigantic mountain of software.
Rob
We seem to be straying a bit off-topic. The thing to remember is that what you personally think about ODF and OOXML doesn’t matter so much unless you are on a committee that recommends the voting position for a JTC1 P-Member.
Warren Buffett had a nice story he told, about trying to predict the winner of a beauty contest. (He was really talking about picking stocks, of course, using this as an analogy) The trick, he said, was not to spend all your time looking at the pretty girls and trying to determine which one was the best looking. The trick to predicting a winner was to look at the judges. Are they all middle age men, nuns from the local Catholic school, frat boys, etc? Knowing the preferences and inclinations of the judges is more important that knowing your own personal preferences.
The point of this post was to point out that the judges in this beauty contest have demonstrated that they do not like it when their contradiction arguments are ignored.
As programmers, we are taught to look very carefully at our code to avoid “logic bombs”, where unexpected conditions come to the fore and the program goes on holiday.
Now ECMA has ratified the ECMA 376 file format as being necessarily, by definition, compatible with MS Office 2k7’s MS Office Open XML file format.
And Microsoft has released the MS Office 2k7 to the public, so Microsoft is not in fact in any position to change anything dramatically. Nor is ECMA, as a result.
This constitutes a logic bomb of truly interesting – as in the benison/curse “May you live in interesting times” – dimensions. If ECMA TC45 were to bend to public demands, and alter the ECMA 376 standard to answer the criticisms, it would no longer be operating according to its charter. It would be making its standard incompatible with MS Office 2k7’s file format.
And Microsoft it seems, is not interested in correcting its Office 2k7 to conform with a revised ECMA 376.
And some of those JTC objections are truly showstoppers.
Ever seen a car upside down, wheels spinning helplessly? Remember that while you watch Microsoft doing battle with the international standardization organization. In operating system studies the situation is what is called a race condition.
Dobra chut, Microsoft! Bon appetite!
Wesley Parish
@wesley parish
That is why you have versioning.
Ecma could just bring out a 1.1 version similar to ODF has done.
Microsoft can stay on OOXML version 1.0 until their first service pack.
I think it is probably commitment to making such changes in future versions that ISO national bodies would want to see in Ecma !!!
3 Microsoft employees have been at the SC34 meeting in Oslo during the last 3 days and about 2 other who probably have strong dependencies.
To ‘the wraith’ latest comment.
In fact they could if they had chosen to start small and smart and to grow thereafter. OOXML 1.0 is already charged with a host of unacceptable features (including but not limited to the whole series of deprecated behaviors from ancient MS Office products).
They should have had a closer look at the other way round: start with the core, complete as needed and as genuine requirements mature. But then it might have been harder for them to contend that their proposal needed to depart so radically from the existing standard – ODF.
i would like to cite a recent comment submitted by someone to the “call for comments” of the Standards Council of Canada (SCC):
“
Any effort to standardize a document format needs to consider long-term document storage and retrieval. For this, the standard needs to be fully self-documented. It must be possible to decipher documents 10, 100, or 1000 years in the future without reference to the source code of an existing software implementation.
It is clear that OOXML does not meet this requirement. If Microsoft was to put in the effort to *fully* document their standard, this would not be an issue. However, it would likely become obvious that it is too bloated and unwieldy to be appropriate for a document standard.
Alternatively, perhaps a copy of Office 2007 could be chiselled into rock to become a kind of Rosetta Stone for future generations.”
trully insightful IMHO