Hi @nidujay, Regarding your question:
> What is the downside of approaching it the way TOML seems to be doing? It's a reasonable question to ponder, and something I've considered. Since it has been suggested several times already, it's important to address it head on. >From a technical and code ownership standpoint, nothing is preventing us from slapping together a normative document and pushing it to GitHub. But AsciiDoc is vastly more complex than TOML and has much broader adoption. It's more akin to Markdown. And we can learn from what happened with Markdown. They took a roll-your-own approach to making a spec, didn't secure rights to the name, had to change the name to CommonMark, sparking all sorts of conflict and in-fighting, and lost the authority over the definition. Now, the world has one more Markdown fork / variant that has only narrow adoption. We don't want that to happen with AsciiDoc as a result of not doing our due diligence. There are a lot of complexities in creating an authoritative spec that goes beyond what an Open Source project has to deal with. We want to end up with a definition that everyone agrees is AsciiDoc. We want it be versioned. And we want to sprout multiple, compatible implementations. All that's going to require consensus building, process, and governance. That doesn't just happen by accident. If we just slap it together, the spec will have very little meaning, other than one more fork / variant of AsciiDoc. We also need the spec body to manage the use of the name so implementations that call themselves AsciiDoc are in fact AsciiDoc per the TCK. Without a governing body, there's no enforcement. And if there's no enforcement, the meaning of AsciiDoc gets watered down and we lose control over it. Maybe that doesn't matter for TOML, which is simple enough. But it will matter a whole heck of a lot for AsciiDoc since it's already used to store large amounts of critical information. It must be something that can be written and parsed consistently. So could we do without a formal process? Sure. You could also drive without insurance or have a society without a governing body. But it's extremely risky. I'd argue it's foolish. Everything is fine until it's not fine. At that point, it's too late to address the damage. The whole point of tapping into the expertise of a standards body like the EFSP is to not have to stumble through solving process problems when they inevitably come up. Instead, all the policies and protections are already in place. And if you think we won't have patent or trademark issues, then you haven't been paying attention to tech in the last decade. It's not a matter of if. It's a matter of when and whether we will be prepared. To conclude, there's no point in doing a spec if it isn't done right. In fact, if not done right, it could be detrimental. At worse, it could compromise the integrity of this great language we've invested in. At best, it will be ignored. Instead, we want to secure the future of the language and give it space to evolve. Best, -Dan -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/asciidoc/CAKeHnO7C-Rcyyw6999qFugo5%2BDcxSOywr3srSnKTjTK0JB97EA%40mail.gmail.com.
