在过去的一年里，社区多次呼吁制定AsciiDoc规范，显然大家都期待AsciiDoc走这一步。我们同意这一点。我们也联系了AsciiDoc的创始人Stuart，得到了他的支持。所以，现在是追求这一目标的最佳时机。
一处新家在Eclipse基金会
我们希望AsciiDoc有一个强大的未来以及它发展和成长所需要的资源。为了实现这一点，我们决定向Eclipse基金会提交一个AsciiDoc语言规范的提案。Eclipse基金会为发展规范提供了家园，并且致力于透明度和开源，这些价值观与AsciiDoc及其社区高度一致。Eclipse基金会规范过程（EFSP）提供了一个清晰且可定制的结构，这降低了过程停滞的风险，并确保最终结果在现实世界中是可用的。该过程是公开的，厂商中立的，所有源材料和最终成果都是开源的。
AsciiDoc成为一个规范将意味着什么？
AsciiDoc语言规范将包括一个开源规范文件，该文件定义了必需和可选的API定义、语义行为、数据格式和协议，以及一个开源的技术兼容性工具包（TCK），开发者可以使用这个工具包来开发和测试兼容的实现。（那些从Asciidoctor之前就认识Dan和我的人知道，一个开源的TCK对我们来说是一个硬性要求）。根据EFSP（Eclipse基金会规范流程）所定义的兼容实现，必须完全实现规范版本的所有非可选元素，必须满足相应TCK的所有要求，并且不得更改规定的API。
对用户和开发者而言，AsciiDoc规范将意味着一个清晰、可行的定义，指出AsciiDoc是什么以及如何解释它。开发者将能够围绕AsciiDoc构建实现、工具和服务，而不必担心其含义被稀释或分化。反过来，用户将拥有更多选择，更大的文档可移植性，以及兼容实现和工具将根据版本化的规范处理他们的AsciiDoc文档的保证。
Asciidoctor会发生什么？
我们计划将 Asciidoctor（RubyGem）打造成一个独立的、与 AsciiDoc（规范）兼容的实现。（这并不意味着 Asciidoctor 整体将转移到 Eclipse 基金会）。这可能意味着为了通过 TCK，我们需要在 Asciidoctor 中添加、删除或更改特性以符合规范的必需和可选元素。如果愿意，Asciidoctor.js 和 AsciidoctorJ 项目也可以决定成为拥有比以前更大自由度的独立、兼容的实现。而且，这将为新兴的实现提供空间，将 AsciiDoc 带到更多平台。
一旦规范制定流程启动，我们将了解更多信息，并将持续更新你所期待的内容。
准备好了吗？就定。规格！
创建AsciiDoc规范的下一步是向Eclipse基金会提议将其作为一个规范项目。我和Dan（代表Asciidoctor以OpenDevise的身份）计划提交的提案将由Eclipse管理组织审查，然后公布让社区审阅和评论。要了解更多关于规范过程的信息，我鼓励你查看Wayne Beaton的文章《EFSP第二部分：EFSP》和《EFSP第三部分：创建》。规范过程是Eclipse开发流程的一个分支，你可以在《EDP第一部分：EDP》中了解。你也可以阅读《EFSP文档》。
通过一个可以根据AsciiDoc社区需求来调整的规范过程，Dan和我相信这种语言将以可持续和有实质性的方式发展，能够跟上社区现在和未来的需求。我们真的很兴奋能够开始这个过程，希望你们能加入我们，一起将AsciiDoc变成一个规范！