Lex, Thank you for your support.
As always, you raise thought-provoking questions. If we had answers to all these questions, we'd already be at the end of the specification process (or at least well into it). Proposing a specification isn't about showing up with answers to all these questions. Rather, it's about initiating a process where these questions can be answered. While these are fantastic questions that serve as a springboard for discussion, we're getting ahead of ourselves thinking we need answers first. The proposal itself is surprisingly simple. It's an intent. It gets the process started and reserves the space and resources for the process to be conducted. Here's an example of one such proposal: https://projects.eclipse.org/proposals/jakarta-ee-nosql I can directly address the question about what we're standardizing. My intention is to standardize the AsciiDoc language, first and foremost. That is, defining the structure and syntax in which information is being encoded under the name "AsciiDoc". I've always viewed AsciiDoc as having a very well-defined structure, albeit with some gray areas I'm confident we can address. No matter how far we take this, we at least need a language definition, so it's step one. I'll pull something up from the bottom of your post that fits here: To me the point of the standardisation process is to ensure that markup in > a document is interpreted in the same way in all implementations, and the > semantics of that markup are the same, not its presentation. That's the > core of the "AsciiDoc is a semantic markup, not a presentational markup" > statement. > 100%. This would serve as great raw material for the proposal. We may consider certain outputs to be optional parts of the spec, as I explain below. I will *speculate* about the answers to some of your other questions as a thought experiment. But nothing I'm about to say here should be construed as an official position until we're into the specification process. any output used in the specification means an implementation must provide > that format to demonstrate compliance, or if the standard tried to specify > all outputs it is preventing new targets from being "standards compliant". > ... > that unfortunately makes it difficult to generate automated tests > I don't think so. I believe we can validate the parsing of the language by defining an intermediary, output-agnostic data format (an object notation). If you look at Asciidoctor, this is what the AST is (though too amorphous in its current state). Once you've proven that you've parsed the document and captured all the information, I believe you can claim compliance (at least to interpretation of the language). And that's what the TCK should focus on. That being said, converters to certain output formats are a great example of an optional requirement (at least for the language portion of the spec). We can imagine an implementation that only cares about parsing, such as for use by an indexer. So there's no need to mandate anything more than that. But it might still be important to specify built-in converters to HTML, DocBook, and perhaps DITA to make the specification functional. I think we can do it in such a way that allows for plenty of experimentation. In other words, the converter would be defined as an API you can implement however you like. An implementation can provide the (optional) built-in converters, or it can just go wild and make it's own (with the understanding that those outputs are custom). also would mean any styling customisation is "not standard". > Personally, I think roles have already solved this problem. AsciiDoc has proven this simple abstraction allows for tremendous styling customization. I think that will give us a lot of flexibility. (Another idea is to support data- attributes as a direct mapping to the output, which would really open things up). And designing a new "standard output" during the standardisation process > without an implementation is risky. > On this matter, I can be specific. Eclipse doesn't allow a standard to be defined without an implementation. It's a "come with code" specification process, as Wayne details in his posts. So this is not a risk. Now, back to speculating. If such an implementation (output may be used in different environments) > cannot be standards compliant, there is no incentive to implement all of > Asciidoc, and no incentive to not add some new markups just to suit their > use-case. That way just leads to fragmentation. > Based on what has been said so far, this concern seems contrived. We get to define the specification in our way, and the Eclipse Specification Process allows for this. So we'll define it in a way that will afford plenty of output flexibility. That's certainly a key requirement to make it useful in the real world. It's safe to say we're all keenly aware of the risk of fragmentation (having learned from Markdown), so we'll take necessary measures to prevent that situation. This specification is about building a common understanding, not as a tool to exclude ideas and innovation. What about generated content that is not a direct transcode of input, such > as tables of contents, indexes, section numbers. Which organisation of > those is to be standardised? > This is likely going to be a follow-up specification that deals more with publishing concerns. I don't see a table of contents and index output as part of the language (certainly the structures they're built from, but not what's generated). This has more to do with how the language gets used. Perhaps an addendum specification down the road can address it. I want to finish by clarifying that I don't make light of any of these concerns and questions. We just don't have to (and shouldn't) solve them today. I'm targeting the Eclipse Foundation Specification Process because I believe it will provide the platform to facilitate the discussions around these questions and help us address these concerns. AsciiDoc certainly deserves that foundation. Cheers, -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 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.
