Thanks, Lex. To be clear, I believed we were only talking about parsing test specifications here, not AsciiDoc source. I would not see an EDN parser being involved in that process in any way.
Cheers,
IIUC Sylvain is talking about the form of the test specifications for "AsciiDoc" compliance, a mapping between an input AsciiDoc source and the resulting abstract syntax tree/graph. He is suggesting this be represented in JSON format. As I said, most things in that tree are likely to be JSON compatible types e.g. nested maps, strings, and ordered sequences. It is the tree shape that is most important and recognising attributes second.
As he indicated a test specification that maps to an output sequence (eg HTML5) would mean that technically only a tool that does exactly that could claim "AsciiDoc" compatibility. So tools that only created XHTML, or docbook, or PDF, or did additional document checking (linting) could not claim AsciiDoc compatibility without the Eclipse foundation lawyers knocking at the door about the AsciiDoc trademark. That may seem petty, but it is the lawyer's job. IANAL but IIUC if a trademark violation isn't pursued you lose those rights.
Sylvain's suggestion that "AsciiDoc" be defined to the AST, and tests for that be available, gets around that issue and assists in having a common base for extension definitions.
Of course that doesn't stop the HTML output being specified as well, but again if it is specified and a test set defined, it can't evolve without the specification changing. And that is likely to not be a fast process.
Cheers
Lex
...
I don't know which form the TCK will take. As for myself, I would push
toward a set of 2-tuple mapping an input string with a
language-independent (aka JSON) representation of the expected DOM/ASG.
+1
James' following objection is noted, but I don't think the specification should define if sequences are lists, vectors, or dictionary/maps indexed by integers, that is too implementation specific. Nearly everything is text, so a parser is working right if it recognises "2.0", I doubt if its floating point representation is going to need to be specified for AsciiDoc purposes. Same for other types.
More important is the shape of the AST. Again if sequences of children are implemented as a C++ std::vector, or a Lisp list should not matter.
Cheers
Lex
Anyway, everything is open to discussion. So don't hesitate to share
your thoughts on the subject!
Regards,
- Sylvain
_______________________________________________
asciidoc-lang-dev mailing list
asciidoc-lang-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/asciidoc-lang-dev
_______________________________________________
asciidoc-lang-dev mailing list
asciidoc-lang-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/asciidoc-lang-dev
asciidoc-lang-dev mailing list
asciidoc-lang-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/asciidoc-lang-dev
