I really don't understand the comment of a trade secret. AsciiDoc Python and Asciidoctor are some of the most open projects out there. The software is maintained 100% by the community and always have been.
You're confusing a defacto standard with something that's not well defined. A defacto standard is one where the standard is born out of the implementation. This is not necessarily a bad thing. It's one approach to making a platform. (A good example of this is Spring). This approach has carried AsciiDoc along for many years and has worked well so far. But now that AsciiDoc is becoming more pervasive and there's a need for multiple implementations, we can see that a specification of the core language would be very useful. So we've reached a transition moment. Let's just acknowledge it as that. Right now, Asciidoctor is the leading implementation and it's test suite maintains the definition of the modern language. If there's a reference for the specification, that would be it. But we have mostly held back changing things in the language for fear of breaking existing documents. (I've often spoken of this). We experimented with some language changes in Asciidoctor 1.5.0 and I'll admit it was a little rocky. So I also think a specification would help us to evolve faster. And I definitely like that idea. Best, -Dan On Mon, Dec 10, 2018 at 3:35 AM Dan Allen <[email protected]> wrote: > First, I want to start off by saying I don't like your tone. Yelling at us > to do something isn't going to make us do it. And no one is making you use > it. This is an open source project run by volunteers. We do what we can in > the time and resources we have. And we do it because we're passionate > about, not to meet some expectation that someone tries to impose on us. We > work within the constraints that we have. > > I am passionate about AsciiDoc and I want it to have the best possible > future it can. That's why I can share that movement on a specification is > going to be happening soon. (And this is no secret as we've been talking > about it for some time). That's all I'm prepared to say right now. It's not > a commitment that can be taken lightly. It takes time, resources, and > support, and we want to do it right. AsciiDoc really grew rapidly in recent > years, so we have growing pains. We know that. The time is right to get > serious about addressing these matters. > > I want AsciiDoc to be well defined and I want to foster an ecosystem of > implementations. That's something I've looked forward to for a long time. > And I'm really looking forward to it coming to fruition. If things go as > planned, I'll be posting a proposal fairly soon. > > Best, > > -Dan > > On Mon, Dec 10, 2018 at 3:10 AM Jaime Tarrasa <[email protected]> > wrote: > >> >> El domingo, 9 de diciembre de 2018, 0:32:57 (UTC+1), Lex Trotman escribió: >>> >>> >>> Currently there isn't a specification, its on the todo list of a >>> number of people, but nobody has had the time available to do it. >>> >> >> ??? >> So when people in asciidoctor write code they do it on the fly. Someone >> says "I'm going to implement this". Nobody writes it down, the coder >> programs it, but has no time to write what the program was supposed to do. >> So to know what asciidoctor does they skim the code. >> >> Having multiple implementations is good for the ecosystem >> >> >> If they are compatible. >> There is no specification, so. Multiple implementations of what? >> Do asciidoctor and asciidoc.org have a private chat to talk what the >> standard is? >> With no written standard, what you are going to get is divergent >> implementations and probably a fight to rule standard. >> >> >>> (eg Asciidoc >>> Python can't be used by github, but Asciidoctor being Ruby can be), >>> but the intention is to try to avoid the markdown scenario where >>> everybody has their own variant. >>> >> >> No success. You already have two incompatible variants. And only because >> nobody else has decided to implement it. >> >> >>> >>> Hopefully the specification effort will begin in the new year. >>> >> >> Once again. The implementation must already be there, somewhere. I don't >> believe they write code from the empty air. But apparently they keep it >> like trade secret. >> >> >>> >>> > >>> > Reading users guide, examples, blogs and FAQs I can gather scattered >>> information so I can "reverse engineering" for a parser, but with are lot >>> of doubts. >>> > One of the supposed advantages of asciidoc over markdown is that there >>> are not a lot of incompatible flavors. But it looks that the standarization >>> of asciidoc comes from having only two "de facto" parsers: asciidoc.org >>> and asciidoctor.org, (and now asciidoc3.org?) >>> >>> Effectively the current standard is asciidoctor, its the one actively >>> maintained and enhanced. >> >> >> What you say is that asciidoc is not a standard format, but the >> implementation of asciidoctor. >> The (current) committee that rules asciidoc format is in asciidoctor. >> They deliberate what enhancements, reforms and changes to make. And when >> they reach an agreement, instead of publishing a specification, they >> publish the new version of the toolchain and an article with an overview of >> changes. I suppose that until someone dethrones asciidoctor as the owner of >> standard... maybe looking things from this point of view the trade secret >> concept makes sense. >> >> People who writes in asciidoc must trust in asciidoctor, not in a >> inexistent public standard format named asciidoc. Is this the portable >> standard that was going to end with markup languages wars? >> >> I'm really astonished. >> >> >> Well, if you don't have a huge investment in Asciidoc Python, then the >>> advice is to use the Asciidoctor implementation, as I said its the one >>> thats maintained and enhanced, so not needed at the moment. >>> >>> >> I am translating a book and I wanted to convert it to several formats, >> basically FB2 and HTML. I wrote the book in asciidoc format and wrote a >> translator in Pascal language to generate FB2. My parser is very simple >> because my documents are very simple, I only used a few features. I could >> have used any lightweight markup language (in fact, I could have created my >> own markup), but I chose asciidoc because I read it was very standard and I >> wanted to remove the dust of my programming skills programming a parser. >> >> After programing a simple parser that only was aware of a few markup >> features, I was going start implementation of the full-compliant asciidoc >> parser. But there is no such thing, there is no specification to be >> full-compliant of. I wanted to write a parser for a standard format not to >> chase a hidden moving target, so I won't do more investment in Asciidoc, >> let it be Asciidoc-python or Asciidoctor. >> >> Asciidoctor and asciidoc-python guys, you'd better move to the top of the >> list writing a specification, stop anything you are doing, and publish the >> specification, better today than tomorrow, moreover better yesterday than >> today. >> >> -- >> 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. >> > > > -- > Dan Allen | @mojavelinux | https://twitter.com/mojavelinux > -- 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.
