US V1 technical committee votes to recommend Approval of DIS 29500


I just got off a 3-hour call with my colleagues on the V1 technical committee, in which I and the other members of the US delegation to the BRM presented our thoughts on what happened at the BRM. Then we all voted on what to recommend to the INCITS Executive Board for the final US position on DIS 29500.


The final outcome: we are recommending that the US maintain its Approve position on DIS 29500. The next step will be for the INCITS Executive Board to conduct a letter ballot to approve this result.


After all the hard work in V1 going back to the beginning of last year, it’s great to have finished up our review of DIS 29500 on a positive note. I think the interests of the United States have been well served by the process, and the spec is much better now than when we started.


More details later. For now, I’m looking forward to a weekend at home!


Comments (46)

  1. Doug Mahugh just posted about a call this afternoon where the U.S. V1 technical committee voted to approve

  2. I just saw this come through in email, and would point you to Doug Mahugh’s blog that the US V1 technical

  3. hAl says:

    I had little doubt about that vote even though I was rather surprised to see the voting of the US delegation at the BRM.

  4. gopi says:

    Did the BRM actually publish the full list of changes? I haven’t seen that publicly available, but obviously the technical committees would have access to non-public info.

    Have you had a chance to read through all of the changes that were approved and those that were rejected, and made sure that they were all consistent?

    Or, did you decide that the BRM’s result was sufficient without needing to do a detailed review?

  5. krp says:

    "we are recommending that the US maintain its Approve position on DIS 29500."

    You people should hang your heads in shame.

  6. Conrad Mazian says:

    Methinks that the USA has made a mistake on this issue. I’ve been involved with standard in the past with Underwriters Laboratories, Industrial Truck Standards Development Foundation, and ISO. The rule is that when there are serious problems with a standard, you bounce it back. And there are serious problems with this standard. References to things that are not in the standard (or in any other standard) are probably the biggest issue, but there are others.

    I cannot see how the US position on MS-XML is justified.

    Conrad

  7. dmahugh says:

    @hAl, me too.

    @gopi, I’ve read the changes approved in Geneva (and I was there), and I’ve read nearly all of Ecma’s proposed dispositions that were accepted.  I think the changes are improvements for the most part.  FYI, I know we have at least two people on V1 who have read every disposition.

    @krp, let’s get out and get some fresh air and perspective this weekend, OK?  I’ll go first.

  8. dmahugh says:

    @Conrad, do you have any specific facts you’d like to discuss, or is this just a "feel it in my gut" thing for you?  If it’s the former, I’d be glad to discuss the details.

  9. krp says:

    I get fresh air every single day.  You people should still hang your heads in shame.

  10. Conrad Mazian says:

    Doug,

    I was thinking specifically of the references to the older binary file formats, which aren’t properly documented, are the biggest issue. In fact I think that this is a killer issue – a standard which references unknowns is not a standard.

    Conrad

  11. David Lane says:

    Hi Doug,

    You, along with your MS comrades, continue to take unwarranted liberties in referring to MSOOXML by the name "OpenXML".  

    As an American (now at home in New Zealand), I’m deeply ashamed of the US body if they’ve voted to accept the MSOOXML format. It’s simply wrong to pollute the world with a second office format standard.  ODF was first and Microsoft has had every opportunity to influence it’s development.  It has chosen not to.  Now Microsoft is rewriting the rules of the game (at the expense of ISO’s reputation) because without doing so, it would have to compete on a level playing field.  Make no mistake: MSOOXML isn’t open, and it’s not "for the customer’s best interest".  It’s for Microsoft’s bottom line.  And that’s not compatible with ISO standardisation.  

    Remember: multiple implementations of the same standard is good for everyone (except incumbent monopolies) and multiple standards for the same things is bad for everyone (except incumbent monopolies).  

    Hands up if you have two socket sets in your toolbox – on for metric and one for American Standard nuts and bolts.  A waste of steel and money, eh.  But that’s just the tip of the iceberg for the travesty of two standards for the same thing.

    Think about it.

    Dave

  12. Ton says:

    Please provide links to the ANSI or INCITS documents that provide the bylaws, guidelines, principles, or other criteria that V1 and the INCITS board are obligated to follow when acting on an ISO standard item.

    Thank you.

  13. mordonez says:

    @Dave

    Fortunately for the rest of the world, not everyone subscribes to your view that "first" to standardize precludes other choices.  

    If everyone thought like you, TCP/IP and the internet would never have happened.  We would all be trying to figure out Open Systems Interconnection (OSI)

    http://en.wikipedia.org/wiki/Open_Systems_Interconnection

    No Internet. No web.  We woud not be having this conversation.

  14. David Lane says:

    @mordonez,

    How ironic that you’d pick OSI as a counter example.  I think we could both agree, for example, that:

    1.  if the Metric System had predated the incredibly ponderous and legacy-encumbered American Standard system of measurement (5280 ft to the mile, for example), then I think everyone would be able to agree that someone suggesting that introducing an American Standard measurement standard would’ve been stupid.  Do you disagree?

    2.  Based on the link you provided, TCP/IP came into existence because, clever though it might’ve been, OSI was, in practice, unimplementable.  TCP/IP, on the other hand, was like the Metric System by comparison – simple, practical, and implementable.  

    I’m not saying that standards should hold back innovation – I’m saying that when you have a superior standard like the metric system, it’s damn stupid to try to introduce the American Standard system.  

    I don’t think anyone would disagree that ODF is a much tighter, more practical standard than MSOOXML.   It’s already been implemented to a huge extent by 5 or six *independent* projects (e.g. Abiword, Gnumeric, OpenOffice, Symphony, Google Office, etc.) and it’s 1/10th the size of the MSOOXML spec, and comes without any legacy baggage.  *No one*, not even Microsoft, has been able to implement MSOOXML.  Is it even implementable in it’s current form?  I don’t know…  

    Here’s the point:  I’d say that in this context, ODF is much closer to TCP/IP and the Metric System, and MSOOXML has all the ponderous hallmarks of an OSI or American Standard measurement system.  I’d be interested to understand your rationale if you disagree.  

    Dave

  15. David Lane says:

    I should clarify, @mordonez: I don’t believe that any standard should stand still because that blocks innovation.  I also don’t believe that a bad standard that cannot be implemented should block the standardisation of a better standard.  

    I do not, however, think that anyone could make a solid case for the fact that OOXML is a better standard than ODF.  I also believe that my first point still holds.  Multiple implementations of a single standard are always preferable to multiple redundant standards.  

    Dave

  16. nksingh says:

    @David Lane:

    I don’t think anyone who has actually tried to implement ODF without reusing the OOo codebase will agree with you on the tightness of the ODF standard as specified in the ISO spec.

    It leaves as app-defined several elements that would be of interest to interoperability and it mishmashes several namespaces together when it comes to drawing (it is not actually SVG-based to the point where you cannot drop in an SVG reader to handle the drawing elements automatically… the same tag names are used but the meanings change slightly, according to Jesper Lund Stocholm, a BRM delegate who seems to be implementing both standards).  

    ODF is insufficient for todays MS Office format.  You might be able to represent the same shapes graphically, but retaining editable representations of Office features was not on the cards for ODF 1.0, 1.1, or 1.2.  Maybe it will end up happening for ODF 2.0.. maybe not.  Adding features to a format is a lot harder than removing them, so I think it would be wiser to start the next grand unification format from Open XML and whittle it down using profiles and extensibility points to be as clean as ODF.

    Regardless of what happens at ISO, people in the open source community and the vendor community will have to implement Open XML, so it’s not like anyone is doing less work by starting on ODF.

  17. Liam says:

    <blockquote>Fortunately for the rest of the world, not everyone subscribes to your view that "first" to standardize precludes other choices.</blockquote>

    It does proclude other choices when all they offer is an obfuscated, bloatier version of the first.

    Lucky Microsoft didn’t try pushing a crippled TCP/IP clone through ISO, or we <em>really wouldn’t</em> be able to communicate on the Web.

  18. hAl says:

    [quote]I do not, however, think that anyone could make a solid case for the fact that OOXML is a better standard than ODF. [/quote]

    There are areas where OOXML is a lot better than ODF. If those areas matter to you then there is a solid enouhg case for calling OOXML a better standard than ODF.

    If for instance you are looking at applying the format for business integration purposes using custom data then surely you would take OOXML over ODF.

    If you look at the OPC packaging of OOXML then that is superieur to ODF’s packging.

    If you you look at the DrawingML markup than the chaotic OOo draw based shambles that is in ODF (aka ‘the non SVG compatible format’) is definitly not better.

    The current conformance clause of ODF is total joke. I have no idea how that passed trough ISO.

    In addition to that the maintenance regime with OASIS having full control and ISO with no influence on the ODF format makes ISO members very unhappy.  

    For instance OASIS has not submitted any 1.1 version to ISO because it could not afford to have the standard scrutunized in a standards proces side by side with OOXML because it would not have passed so easy again again without similar major changes as are applied to OOXML.

  19. mordonez says:

    @Dave

    Several of those "independent" projects have also implemented Open XML (Gnumeric, Novell Open Office).

    The example illustrates the point that "first to standardize" should not preclude other choices. If you think that one solution is superior or better meets your needs then that is your choice.

    I hope that you agree that others should have the same freedom to choose.

    I’ll call your Metric / American Standard, and raise you CORBA / web services. 🙂

  20. Doug Mahugh’s blogged that the US V1 Technical Committee recommended approval of DIS 29500 (Open XML)

  21. Doug Mahugh blogged that the US V1 Technical Committee recommended approval of DIS 29500 (Open XML) to

  22. David Lane says:

    @mordonez,

    Interesting points.  I still think that ODF is the far better standard, and that introducing MSOOXML into the mix is like trying to claim that CORBA is the way forward when we already have web services.  

    Oh, among the independent implementations of ODF, I forgot Koffice.  

    Can you give me an idea of exactly how much of MSOOXML Gnumeric and Open Office have managed to implement?  How much of it will run on something other than MS Windows?  My impression is that the answer to both is "not much".    

    I think that ODF is the far better standard.  I think you’d agree that if TCP/IP had been standardised before OSI, then the backers of OSI would’ve looked pretty ridiculous for trying to foist their ugly baby on the world.  I submit that MS look the same trying to ram MSOOXML home.  There’s no way in which MSOOXML is a better spec than ODF.  More importantly, as this is the special case of standardised XML, there’s no reason that ODF cannot encompass the requirements MS might have…  No matter how you look at it, there’s tremendous cost to the marketplace for having 2 standards.  It is always undesirable.  

    The late coming standard must demonstrate itself to be inherently superior to the earlier standard for there to be any possible justification for two.  MSOOXML is *not* superior to ODF, except for the fact that ISO or not, MS will continue to be able to control it, thereby protecting their monopoly marketshare and retaining those clients who need to tick the "open standard file format" box.  

    Don’t you think it’s a bit rich how MS employees insist on referring to the MSOOXML format as "OpenXML" when Ecma have passed stewardship of the format back to MS?   It makes me quite sick to see how badly this process has been gamed for MS’s commercial interest.

    Dave

  23. Doug Mahugh – relayé par Brian Jones – confirme dans son post que le National Body américain, l’INCITS,

  24. Oliver says:

    The discussion in the comments here is a good one, to my mind it is highlighting why the choice of something like a document format has to be a market decision, not a technical or an ideological one.

  25. gopi says:

    @dmahugh:

    "I’ve read the changes approved in Geneva (and I was there), and I’ve read nearly all of Ecma’s proposed dispositions that were accepted."

    So, at the BRM, did you vote in favor of Ecma dispositions that you hadn’t read? I wasn’t there, of course, but I tend to feel uncomfortable voting for things I haven’t read.

    "I think the changes are improvements for the most part."

    Are some of them simply neutral, or do you think that some of them make the proposed standard worse?

    Given the huge number of changes that have been made at the very last minute – and the number of people at the BRM who felt unhappy that they didn’t have the opportunity to have important issues heard, I’m surprised at the push from Microsoft to keep moving forward in this manner.

    I hear people from Microsoft and Ecma arguing that the standard should be approved as it is now and that the remaining issues should be dealt with during maintenance.

    This really makes no sense to me. I thought the point of an approved standard was that it was something ready to be implemented. If there are known, outstanding issues that should be dealt with, and the issue is one of time, why not delay the ratification of the standard until the issues have been dealt with?

    As it stands, your recommendation seems to be, "Approve this standard, don’t worry about the problems we didn’t have time to fix, wait for rev2 and it’ll be better."

    If the standard really is good enough as-is, then you guys need to stop telling people to not worry and wait for maintenance to deal with the rest of the problems.

    If the problems that are outstanding are actually relevant and important, then it’s a serious mistake to knowing approve a standard with mistakes for some strange sort of expediency. A flawed and about-to-be-fixed standard isn’t useful; I can look at the beta version of the standard now. Releasing the beta and calling it a 1.0 is misleading.

    The whole point of a document format as an officially recognized standard is that it is well documented, with clear and complete information that is consistent. The specification as initially proposed by Microsoft was not of appropriate quality for a standards document – it was, rather, a description of how Microsoft had chosen to implement a file format. Many parts of the spec looked to be done a certain way because that’s what a software developer thought was convenient, rather than something that was intentionally designed and considered as the "right way" to do something.

    Given the incredible shortage of time at the BRM, wouldn’t it be better to slow down and at least give the people who wanted to be heard fully at the BRM the opportunity to be fully heard? I find it very difficult to resolve the conflict between the very positive sounding picture you paint here, and the fact that people left the meeting unhappy that they didn’t even have a chance to get their viewpoints properly heard.

  26. Open XML says:

    “I wish my neighbor’s cow would die," Je trouve ce nouveau post de Patrick Durusau particulièrement pertinent.

  27. There is many Arabic issue  in OOXML (including mistakes in the specs). For example the use of different notations for the HINDIARABIC switch argument and the hindiNumbers ST_NumberFormat enumeration value is not clear.

    Also the use of HINDIARABIC switch argument seems is for another type of digits not Arabic-Indic digits.

    and many others. This proposal didn’t have a chance for careful review due to iso fast track very limited period.

  28. andre says:

    mordonez,

    gnumeric, novell: yes, they at Novell support Open XML because they believe in the format. A belief in the format that is documented by contractual obligations and hard cash from Microsoft.

    No market player implements the format independently! (*)

    The "Open XML community" is a Potemkin village of hired cheerleaders.

    (*) Oh yes, IBM lets you parse the XML with XML editors, what an "implementation" of the format.

  29. Tom says:

    Hi Doug, I would appreciate a set of links to INCITS and ANSI that provide the bylaws, principles, and guidelines that provide the governance and decision criteria used by V1 and the INCITS board when voting on ISO standards proposals on behalf of all citizens of the USA.

    Thanks!

  30. dmahugh says:

    Thanks for all the feedback, everyone.  In no particular order …

    Patrick Durusau, the chair of V1, has posted his thoughts on the outcome of Friday’s meeting here: http://www.durusau.net/publications/russianpeasant.pdf

    @krp, your opinion and lack of supporting facts is duly noted.

    @Conrad, ditto.  (Sorry, a vague reference to things that "aren’t properly documented" isn’t the same as referring to specific text in DIS 29500.  Section #?  Specific quote from the DIS?)

    @Dave, regarding the name, I use the name that appears on the cover of DIS 29500, less "Office" which feels redundant to me.  Your suggestion, on the other hand, is a fabrication used by various lobbying groups that has never been used by ISO/IEC, ITTF, Ecma, or any other organization officially involved in the standards process.  I’m comfortable with letting others reach their own conclusion on which of those approaches constitutes taking "unwarranted liberties" with the name.

    @Tom, I don’t know where those bylines are so can’t help on that one.  I’d recommend you ask INCITS or ANSI for such information.  For what it’s worth, nobody involved has suggested that any rules have not been followed properly, including those who have consistently voted against DIS 29500.  The chair of V1 specifically asked whether anyone had concerns about voting procedure at the end of yesterday’s call; none were raised.

    @gopi …

    > So, at the BRM, did you vote in favor of Ecma dispositions that you hadn’t read? I wasn’t there, of course, but I tend to feel uncomfortable voting for things I haven’t read.

    Me too, and that’s why I recommended that the US take an "abstain" position on the comments we had not reviewed within V1.  As of Thursday afternoon we had 100% consensus within the US delegation that "abstain" was the only reasonable position to take, but early Friday morning I found that several members of the US delegation had decided overnight to recommend "Disapprove" instead.  You might ask some of them why they chose that position, or share with them your discomfort on the US taking a position on things we haven’t read.

    > Are some of them [accepted dispositions] simply neutral, or do you think that some of them make the proposed standard worse?

    Some are neutral.  I know of no disposition that was approved at the BRM which makes the standard "worse" in any objective sense, and I’ve found the lack of specificity in complaints about the BRM results rather interesting.

    As for your comments about whether it would be "better to slow down" at the BRM, I personally had no say in the process for the BRM.  But I think Alex Brown an Gabriel Barta did a good job of maximizing our collective productivity under the circumstances, and most people who were there seem to agree with that perspective.

  31. hAl says:

    @doug, the only really specific items I have seen mentioned I have seen mentioned about the BRM improved specification are ‘

    a) Adding a mapping to the spec was not discussed (Brazil). As no such mapping was abvailable at the BRM there is no way the BRM could have added it anyways. So any discusions on that subject would hve been a useless waste of time anyways. There is of course a Microsoft sponsored project to produce such a mapping. I asume the suggested disposition, Ecma referencing the project which is making that mapping, was accepted at the BRM.

    b) XML naming. Malaysia had submitted a comment that would involve renaming a lot of the xml element names. That surely is to much a a change for a fasttracking BRM. It is hardly a showstopper really even if some element nameing could have been more improved it does not make for that much improvement in using the format. This issue was actually discussed at the BRM but the Malaysian renaming edit proposal was not accepted

    c) An issue was mentioned by a malaysian delegate about being unhappy with the Ecma disposition on the many definition of the e element (a UK issue). It seems like a very minor issue though.

  32. hAl says:

    [quote]As of Thursday afternoon we had 100% consensus within the US delegation that "abstain" was the only reasonable position to take, but early Friday morning I found that several members of the US delegation had decided overnight to recommend "Disapprove" instead.  You might ask some of them why they chose that position, or share with them your discomfort on the US taking a position on things we haven’t read[/quote]

    I did wonder about that.

    I asume that certain delegationsmembers had planned together to vote disapproval on a lot of dispositions in the hope that most would fail. It is rather a strange step to agree with the form voting procedure and then ‘out of principle’ vote to disapprove dispostions in bulk on comments of other ISO national bodies.

    Especially when seeing the effort the other ISO member had put in scrutiny and solving the issues in those comments.

    And if you would have been informed of such planned disapproval voting in the US delegation on thursday Microsoft and or Ecma might have had time to lobby other delegations to vote for approval on friday.

    So changing the vote overnight is, well, rather a sad move by those people.

  33. dmahugh says:

    Yeah, it sure does look strange.  I don’t know how soon we’ll be able to share details of specific votes and dispositions, but there are cases where the US asked for something in a comment, Ecma said "agreed, here you go …" and by our blanket disapproval we were the swing vote that then rejected that disposition.  In other cases, our request was granted in spite of our own No vote.

    As for the considerations of who could lobby whom overnight Thursday, I was clearly not thinking in terms of the politics and got blindsided by the Friday morning reversal.  When our HoD congratulated all of us late Thursday on our ability to work effectively together despite our commercial differences (immediately after we had all agreed that Abstain seemed the only reasonable position on the undiscussed comments), I had no idea we were just positioning and hadn’t actually decided anything yet.  Live and learn.

  34. Anonymous Coward says:

    Some perspective for the V1 committee vote from the blogosphere:

    "

    The thing to remember is that the US decision is not made by V1. It is made by the INCITS Executive Board (EB), and they have until March 26th to make their decision.

    V1, the technical committee, has been heavily stuffed with Microsoft business partners and the 12 of them comprise over half of the committee. Combined they submitted zero technical comments on OOXML. They have voted as a bloc on every technical and procedural vote since they joined V1 last summer.

    Luckily, the EB is more balanced. They are the ones, for example, that picked the US BRM delegation. So, the EB decision will be the important one.

    "

  35. dmahugh says:

    Well, Anonymous, I’m not sure you’re going to find many people, in V1 or the EB or anywhere else, who agree with the "perspective" you’re providing here.

    The vote in V1 on Friday was overwhelmingly lopsided.  Let’s just say that it was a lot more than Microsoft and Microsoft partners on the Approve side, and many more than the 12 you mention, including people who voted against DIS 29500 last summer.  As for "since they joined V1 last summer" I’ll just say that half the votes in IBM’s block came from the very last organizations to join V1 last summer, period.

    As for the balance of the EB being reflected in how they picked the US delegation, many have noticed that after the EB picked a "neutral" HoD (in their second attempt), that HoD was then the lead cheerleader for the anti-DIS 29500 crowd in the days after the BRM, being quoted on the home page of NOOOXML.ORG and similar sites.  Does that make the EB look "balanced"?  The public will have to decide on that.

  36. hAl says:

    I wonder how the HoD and other disapproval voters in the US delegation would explain to INCITS voting no on fully granted dispositions made to the US own comments ?

    That is just terrible.

  37. orcad says:

    Courts will decide if your company stuffed the committee in the US with your 12 business partners.

    See you in court after the 29.

  38. dmahugh says:

    Thanks, Pieter, that was great.  I’ll try to return the favor before long.  I think this should be our standard mode of communication on document standards, actually.  Imagine if during the BRM each country were allowed to sign a song when their turn came — now that would be cool!

    Yes, Orcad, I’ll "see you in court" as the cliche goes.  Wear a red rose or something so that I’ll know it’s you, OK?

  39. Bob Jones says:

    Microsoft’s technology can’t stand on its own technical merits so it has to bribe US Politicians to forward its monopolistic agenda. Its truly sad that our politicians are so unbelievably stupid.

  40. dmahugh says:

    Well, Bob, I agree with your sentiment about our politicians, but I’m not aware of any politicians — or bribes — involved on the topic at hand.  Feel free to share some facts if you’d like.

    By the way … are you related to Pam?

  41. Bob Jones says:

    Microsoft and its associated industry groups (which it heavily funds) have become one the biggest campaign contributors and lobbying efforts in the country. We all know that corporate campaign contributions and just a legal version of bribes. Remember the DOJ lawsuit and how it just went away when the politicians changed. how convenient. you ISO organization has no real credibility any more and is really just a mouth piece for us industry. So instead of the government doing its job of being objective, its just bowing the political pressure of companies  like Microsoft. MS has tried to improperly manipulate the entire ISO process both in the US and europe. Luckily most of the europeans were smart enough to see through MS’s efforts. Unfortunately the US and Swedes were not.

  42. Tom says:

    Found it:  ANSI Essential Requirements (for itself and its Standards developers)

    This document,

    ANSI Essential Requirements:

    Due process requirements for American National Standards

    January 2008

    Found in the ANSI Public Documents Library,

    http://publicaa.ansi.org/sites/apdl

    Defines for ANSI and its various standards developers (INCITS maybe?) some required principles.

    Included below, from its 26 pages, is some very good language on what is required of standards developers (and I would assume approvers).

    ANSI has declared, in writing, that standards development (which includes approval votes) shall follow professional standards.

    I really like 1.2, 1.3, & 1.4

    I really really like 1.2

    — Excerpt from ANSI Essential Requirements: Due process requirements for American National Standards

    January 2008 —

    1.0 Essential requirements for due process

    These requirements apply to activities related to the development of consensus for approval, revision, reaffirmation, and withdrawal of American National Standards (ANS).

    Due process means that any person (organization, company, government agency, individual, etc.) with a direct and material interest has a right to participate by:  a) expressing a position and its basis, b) having that position considered, and c) having the right to appeal. Due process allows for equity and fair play. The following constitute the minimum acceptable due process requirements for the development of consensus.

    1.1    Openness

    Participation shall be open to all persons who are directly and materially affected by the activity in question. There shall be no undue financial barriers to participation. Voting membership on the consensus body shall not be conditional upon membership in any organization, nor unreasonably restricted on the basis of technical qualifications or other such requirements.

    1.2    Lack of dominance

    The standards development process shall not be dominated by any single interest category, individual or organization.  Dominance means a position or exercise of dominant authority, leadership, or influence by reason of superior leverage, strength, or representation to the exclusion of fair and equitable consideration of other viewpoints.

    1.3    Balance

    The standards development process should have a balance of interests. Participants from diverse interest categories shall be sought with the objective of achieving balance.

    1.4    Coordination and harmonization

    Good faith efforts shall be made to resolve potential conflicts between and among existing American National Standards and candidate American National Standards.

    1.5    Notification of standards development

    Notification of standards activity shall be announced in suitable media as appropriate to demonstrate an opportunity for participation by all directly and materially affected persons.

    1.6    Consideration of views and objections

    Prompt consideration shall be given to the written views and objections of all participants, including those commenting on the PINS announcement or public comment listing in Standards Action.

    1.7    Consensus vote

    Evidence of consensus in accordance with these requirements and the accredited procedures of the standards developer shall be documented.

    1.8    Appeals

    Written procedures of an ANSI-Accredited Standards Developer (ASD) shall contain an identifiable, realistic, and readily available appeals mechanism for the impartial handling of procedural appeals regarding any action or inaction.  Procedural appeals include whether a technical issue was afforded due process.

    1.9    Written procedures

    Written procedures shall govern the methods used for standards development and shall be available to any interested person.

    1.10    Compliance with normative American National Standards policies and administrative procedures

    All ANSI-Accredited Standards Developers (ASDs) are required to comply with the normative policies and administrative procedures established by the ANSI Executive Standards Council or its designee.

  43. dmahugh says:

    Thanks for the detailed info, Tom.  I agree completely: 1.2 covers an important concept regarding lack of dominance.

    I do believe, though, that many of the anti-Open XML lobbyists have unfairly characterized the participants in the standards process when it comes to assessing whether dominance is taking place.  There are two areas where I think things haven’t been portrayed in a reasonable manner: assuming influence based on an expressed opinion, and assuming influence due to business relationships.

    In the first case, it seems that some observers feel that anyone who dares to agree with Microsoft, or disagree with IBM, must have been "influenced" by Microsoft.  This has gone to ridiculous lengths lately, to the point that personal attacks and allegations of bribery and corruption are thrown around very casually, and are based only on the fact that a person has dared to speak their opinion and it doesn’t align with the latest party line from NOOOXML or IBM.  Such behavior is despicable in my opinion, and counter to the whole notion of free and open debate.  There’s no consensus-based process that can long survive a pervasive attitude of "you can either agree with me or you’re corrupt, there are no other options."

    In the second case of assuming influence based on existing business relationships, the problem is more subtle.  Let’s take V1 as an example (the same holds for any of the technical committees).  Yes, there are several Microsoft partners on V1.  But what is V1’s responsibility here to the American people?  It is to analyze a document format specification for preservation of America’s investment in existing documents, and the vast majority of those documents were created by Microsoft software.  So should we exclude everyone who has ever been part of that ecosystem?  That seems insane to me, and I think most Americans would agree: we want people involved who actually understand these details and work with them every day.  I think the makeup of V1, which includes longtime standards and markup experts, various technology companies that work with document formats, large corporations, and others, is exactly what it should be, if the goal is to honestly and intelligently guide US policy regarding DIS 29500.

  44. Dating says:

    I just got off a 3-hour call with my colleagues on the V1 technical committee, in which I and the other members of the US delegation to the BRM presented our thoughts on what happened at the BRM. Then we all voted on what to recommend to the INCITS Executiv

  45. Weddings says:

    I just got off a 3-hour call with my colleagues on the V1 technical committee, in which I and the other members of the US delegation to the BRM presented our thoughts on what happened at the BRM. Then we all voted on what to recommend to the INCITS Executiv