In the last few days, a campaign has started brewing to write an AsciiDoc parser in Rust. Obviously, one of the key missions of this Working Group is to encourage new, compliant processor implementations of the AsciiDoc language. So this is a good thing. However, if we don't provide guidance (and, at the extreme, enforcement), it could lead to divergence and dilution of the AsciiDoc name. I just want to make sure we are in front of this.
I followed up to the post to make it clear that I support the initiative, but also to point out that the AsciiDoc name cannot be used without a mark and can only be applied to implementations that self-certify.
The tricky part, of course, is that we don't yet have a spec and TCK to self-certify against. So it's a classic chicken-egg problem. The Go implementation is in the same boat. The best course of action, at this juncture, is to invite these implementations to participate in the AsciiDoc language project. That way, they can, in essence, pre-certify by being instrumental in laying down the TCK. And the great news there is that we can start developing a multi-language TCK right out of the gate. So it's a win-win!
Sharon / Paul, do you have any other advice for how I should handle this situation? I'm particularly looking for guidance around the use of the AsciiDoc name and the term "compatible", especially at this stage.
Best Regards,
-Dan
--
Dan Allen, Vice President | OpenDevise Inc.
Pronouns: he, him, his
