Hugh Wallis全权负责XBRL国际组织XBRL标准的技术开发。他于2000年1月加入XBRL国际组织，之前是Hyperion Solutions公司的一名软件构架师。Wallis先生曾任XBRL规范工作组组长、XBRL-GL工作组组长和XBRL加拿大地区组织/分类标准工作组组长。他参与编制了XBRL 2.1规范和XBRL国际组织的其他技术产品。

大家常常会对技术标准的创立过程产生误解，即便是许多积极参与其中的人也不例外，XBRL的开发更是如此。我希望通过这篇文章能让大家更好地了解XBRL的开发过程，消除大家对这一过程的一些误解。

许多因素都会导致误解的产生，其中最有影响力的因素可能是人们从软件产品使用过程中获得的经验。商业公司一旦决定生产销售某种软件，就会以最快的速度将其投放市场，以获取收益，然后根据客户体验和反馈意见不断开发并改进软件。也就是说，继测试第一版和第二版（常为提供给早期使用者的不完善版本）推出之后，首个1.0版本将与公众见面，该版本软件通常包含一些计划实现但尚未实现的功能。更重要的是，软件中还将含有许多开发商已发现但并不为大众知晓的缺陷。然后，随着资金的不断注入，开发商根据从客户那里获得的实际操作体验对软件进行进一步的开发，定期推出新版本软件并投放市场。

因此市场往往把1.0版本的产品看成是终极产品，并乐于接受商家的定价。即便公司在此后数年中继续发布1.1、1.34、2.0、3.0等版本的产品，1.0版本产品的问世常常让市场产生该产品已经非常完善并无可挑剔的错觉。遗憾的是，多数情况下，1.0版本的产品并不是非常完善且无可挑剔的。

现在，让我们将它与开发一项类似XBRL标准的过程进行比较。软件和标准相比，最大的不同点在于，标准一经公布机构推荐，再想更改，即便不是不可能，也会变得极为困难。推荐标准的本意是营造一个稳定的环境，让所有的利益相关者在今后一段较长的时期内可以依赖，让软件开发商可以利用其开发他们的产品，从而令参与其中的每一个人都有足够的信心相信那些产品能够互通。

举例说明，设想一项有关电灯装备的标准问世（忽略各大洲在螺纹、电压等方面的地区差异）。各个厂家开始根据这项标准制造电灯、灯泡等产品。然后突然有一天，标准制定者宣布为了解决部署过程中产生的某些问题，必须对该标准进行修改。这时，众多商家和消费者此前所做的巨额投资都将付诸东流，混乱四起。所以，软件开发和标准创立最大的不同点在于，标准的开发工作必须在其被推荐实施时就已经完成，而软件的开发工作理论上可以无限延伸。

正是为了避免这种混乱和浪费，标准的开发过程才会变成像现在这样，并被不知情的观察者评价为速度缓慢并充满官僚主义色彩。然而，标准的开发过程与前面描述的软件开发过程又拥有许多的共同点，我将会在后面与大家进行探讨。

处于开发阶段的标准首次以“公共工作草案”（PWD）公之于众。这是一份不完善的草案，可能仅满足部分要求，并包含一些完全可以修改或删除的功能。一般情况下，工作成果由一系列公共工作草案组成，这大致等同于软件开发中的测试第一版和第二版软件。公共工作草案全部完成后，向大家征询修改意见，最后进入候选推荐版本（CR）阶段。

候选推荐版本等同于一个1.0版本的软件产品，它基本上已经比较完善（已经满足了所有要求，被明确列为“危险”的除外），可以被软件厂商采用。也就是在这个时候，市场将开始考虑采用这种标准，就如同人们可能购买并使用新的、一流的1.0版本软件一样。当然，像XBRL国际组织这样的标准制定机构是非营利性质的，不会从出售标准中获取收益；软件和标准在这方面，以及是否希望尽快问市，是否希望最好在季末前问市等方面，不存在相似性。

大约在这个阶段，标准制定者将会号召大家实施这套标准，以获取候选推荐版本的实际应用经验，同时解决所有可能影响最终标准稳定性的问题。这大致等同于获取用户对1.0版本软件的反馈意见。此时，其他候选推荐版本将会被公布，以解决反馈意见中提出的问题（类似于1.2、1.3、2.0版本的软件）。当两套以上候选推荐版本顺利运行后，标准的开发就进入到最后一个阶段。这个候选推荐过程可能会持续很长时间，因为只有实际执行这套标准，在实际环境中测试，并对其进行必要的调整，人们才会对这套标准的确立抱有信心。软件只有在更新了多个版本后才会被认为是成熟的，标准也是一样。它们最大的不同点在于标准一旦被最终确定就不能再进行修改。

我希望通过这篇文章能让大家更好地了解像XBRL这样的标准是如何创立的。如果您想了解有关这一过程更详细的规则，还可以读一读有关标准创立过程的文件。