【IT168 评论】RubyKaigi 2008上，Ruby的创造者Matz宣布了Ruby标准化计划， 其旨在“改善不同Ruby实现之间的兼容性 [..] 以及为Ruby进入日本政府铺平道路”。标准化工作的第一份提案会提交给日本工业标准委员会(Japanese Industrial Standards Committee)，下一步再提交给ISO，使之成为国际标准。现在，你能找到Ruby标准的第一版草稿(超过300页)以及官方声明。除此之外，还有一个正在建设中的Wiki，希望能以HTML格式提供该标准。
另一个截然不同的联合各个Ruby实现的方式是RubySpec项目，它以社区驱动的方式构建了一个可执行的规范。它是Rubinius项目的产物：
RubySpec项目的目标是为Ruby编程语言提供一个完全可执行的规范，其语法兼容RSpec。[..] 总的来说，该规范服务于两个目标：1)驱动Ruby实现的开发，2)作为一种验证机制。
InfoQ采访了RubySpec之父Brain Ford，了解了他对标准化的看法，以及标准化工作对RubySpec意义何在。
我认为ISO标准化的工作对Ruby非常重要，不仅是对语言本身，对社区亦是如此，在我眼里这个社区包含Ruby程序员、使用由Ruby编写的软件的人，以及不断增长的基于或使用Ruby编写的软件的业务。
在我看来，标准化文档和RubySpec是相辅相成的。文档着重以文本的形式，搭配适当的格式来描述Ruby，更多的是给出Ruby的一个定义。
与此相反，RubySpec着重以代码的方式描述Ruby的行为。除此之外，它还强调用一种可执行的规范来描述Ruby，这也是我们使用RSpec兼容语法的原因。
RubySpec还试图去捕获全部Ruby实现的行为的并集，为文档中记录的各种实现之间的差异提供了可执行的保障机制。例如，并非所有实现Ruby的平台都支持fork进程，哪些实现提供了该特性，RubySpec会提供相应的保障。
这就阐明了ISO标准化文档与RubySpec的一个重要的不同之处。ISO文档可以简单地说语言中的某个方面是要“在实现中进行定义的”，并没有提供更进一步的说明。不幸的是，实现这样一个标准有时是很困难的，就像我们看到的不同浏览器厂商实现CSS标准的混乱局面一样。RubySpec会尝试将没有具体说明的Ruby行为数量降低到最小。
一旦ISO标准化文档成熟之后，我们会在RubySpec中添加一些标签，让某个实现能够运行所有标记了“ISO标准”的内容。这能让该Ruby实现宣称自己是完全遵循ISO文档中指明的行为的。我不知道像这样的结果会不会被那些希望验证一个实现是否遵循标准的机构(也许是政府机构)所接受。
InfoQ：Rubinius会与遵循标准吗?
绝对会的。打一开始，我开始做RubySpec就是为了保证Rubinius能尽可能地符合“标准实现”或MRI(Matz's Ruby Interpreter)。我们在这方面下了很多功夫，RubySpec中只有很少几个地方添加了“not_compliant_on :rubinius”标签。因为ISO标准比RubySpec更宽松一些，所以我希望Rubinius能完全符合"ISO标准"。
Ruby标准的草稿是基于Ruby 1.8.7的，但现在已经有了Ruby 1.9.2。我们向Ruby 1.9的版本管理员Yuki Sonoda了解了Ruby 1.9与标准化相关的一些计划：
JIS/ISO标准草案已经制定好了，Ruby 1.9会遵循该草案。草案设计得比较宽松，它将对Ruby处理程序的限制降到了最低，因此就算是1.8.7这样的版本也会需要类似RubySpec这样的更严格的规范来保证不同实现之间的兼容性。
关于其他的Ruby实现，Gemstone(MagLev背后的公司)的Monty Williams告诉了我们他对标准化工作的看法：
我们当然很赞同提出一个Ruby标准。站在更高的层面来看，有一个被认可的标准能帮助提高Ruby在某些特定部门的采用率。我们希望在Ruby标准最终定稿时能保证MagLev是符合该标准的。
InfoQ：Ruby标准对MagLev的开发有什么帮助吗?
MagLev的很多实现工作都先于标准草案，在这方面，对我们帮助最大的是能有一个兼容性测试套件，它能证明我们符合标准，有点类似于JCK。RubySpec项目就是在这个方向上跨出的一大步。
然而，Ruby标准对未来的实现者有着莫大的帮助，它指明了Ruby的各个细节。
我们的读者又会有何想法：如果Ruby有一个ISO标准，在自己的组织内引入Ruby时是否会更方便一些呢?
