> As I’ve mentioned before, I think that considering cross-language extensions would assure that the spec never gets to v1 and would be unusable should it succeed in getting there. Within java, my personal opinion is that it’s probably reasonable to define typed interfaces for different kinds of extensions ...
Well if the DOM/extension API is _specified_ to be a single language, say Java, then the current alternative implementations will not be standards compliant, even Asciidoctor Ruby. So any implementations that can't present a Java interface can't be standards compliant and become AsciiDoc "like" implementations which don't bother to follow the standard since they have no chance to claim to be compliant anyway, because their extension API isn't Java, or Js, or Ruby ...
Still it would save a lot of work since the standard could just be "Use Asciidoctor Ruby" (or whichever implementation uses the specified language) :-).
[end strawman argument]
David, I think you are overstating the effort for a language independent definition, I looked at your extension docs (well the latest commit as I write 5ee7df anyway) and thats language independent so far. Some language is still implementation specific such as "reading into an array of lines", language that might preclude my experimental processor that memory maps input files, but those sorts of things can be fairly easily changed to "process by line" or similar if that in fact actually needs to be specified. Obviously you have yet to specify what/how "extension points" pass information to the extension code. Since I don't understand Java/Ruby/much Js or the Asciidoctor implementation (other than what Dan has explained over the years) I'm a good test for language independence.
Similarly the API to the DOM only needs to specify functions to be available and what they do "The `combob()` function combobulates the `Section` node and leaves it in the AST" and leave it up to the implementation to define what that maps to in their language, be it `combob(Section*)` in C or `Section.combob()` in OO languages. Similarly for functions to provide access to or modification of node attribute/fields/members/properties and mutation of the AST (adding/deleting/moving nodes).
I said in the other thread "It would be best to specify the API in a human readable but still formal enough language to be machine readable.", that is _best_ case, at least human readable is needed since there must be a description of the functionality, but the more formal the language the better.
Cheers
Lex
PS any extensions delivered with Asciidoctor and always available might just be said to be part of the language, and the fact they are extensions is just an implementation detail.
