I'm excited to share with you some much anticipated news. After numerous calls for an AsciiDoc specification over the past year, it's very clear the community is ready for AsciiDoc to take this step. As we established in previous threads, Lex and I are in agreement. I also reached out to Stuart and we have his support as well. So now's the perfect time to pursue it.
== A new home at the Eclipse Foundation We all want AsciiDoc to have a strong future and the resources it needs to evolve and grow. To achieve this, I'm planning to submit a proposal for an AsciiDoc language specification to the Eclipse Foundation. The Eclipse Foundation provides a home for developing specifications and is committed to transparency and open source, values that align well with AsciiDoc and its community. Specifically, the Eclipse Foundation Specification Process (EFSP) provides a clear, yet customizable structure that reduces the risk of the process stalling and ensures the outcome will be usable in the real world. The process is public, vendor neutral, and all source materials and final artifacts are open source. == What will it mean for AsciiDoc to become a specification? The specification for the AsciiDoc language (which will live at asciidoc.org) will include an open source specification document, which defines all required and optional API definitions, semantic behaviors, data formats, and protocols, as well as an open source Technology Compatibility Kit (TCK) that developers can use to develop and test compatible implementations. (Based on past experience with specifications, I consider an open source TCK to be a hard requirement). A compatible implementation, as defined by the EFSP, must fully implement all non-optional elements of a specification version, must fulfill all the requirements of the corresponding TCK, and must not alter the specified API. For users and developers alike, the AsciiDoc specification will mean a clear, working definition of what AsciiDoc is and how it should be interpreted. Developers will be able to build implementations, tools, and services around AsciiDoc without risk of diluting its meaning or splintering it. In turn, users will have more options, greater document portability, and the assurance that compatible implementations and tools will handle their AsciiDoc documents according to a versioned specification. == What's next? The next step in creating the AsciiDoc specification is to propose it as a specification project to the Eclipse Foundation. The proposal, which I plan to submit shortly, will be reviewed by the Eclipse Management Organization, then posted for community review and comment. If accepted, the process to define it will begin. To learn more about the specification process, I encourage you to check out Wayne Beaton's posts https://blogs.eclipse.org/post/wayne-beaton/eclipse-foundation-specification-process-part-ii-efsp (Part II: the EFSP) and https://blogs.eclipse.org/post/wayne-beaton/eclipse-foundation-specification-process-part-iii-creation (Part III: Creation). You can also find the EFSP documentation at https://www.eclipse.org/projects/efsp/. With a specification process that can be adapted to suit the needs of the AsciiDoc community, I believe the language will evolve in a sustainable and substantive manner that keeps pace with the community's needs, now and into the future. I'm really excited to get started, and I hope you'll join me on this journey to make AsciiDoc a specification! Feedback welcome. Cheers, -Dan See related post on the Asciidoctor blog: https://asciidoctor.org/news/2019/01/07/asciidoc-spec-proposal/ -- Dan Allen | @mojavelinux | https://twitter.com/mojavelinux -- You received this message because you are subscribed to the Google Groups "asciidoc" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/asciidoc. For more options, visit https://groups.google.com/d/optout.
