Every time I see a light markup language I think, "Wow! This is just so cool." But at some point later on it becomes, "Why do they do it like that?" and "Can't they make this easier or more intuitive?" ... Or even "Why the hell did it just screw up that simple text?"
The answer to the latter usually becomes obvious - the mark up syntax is intentionally simple and real input regularly gets confused for mark up. It's something you learn to live with and work around using whatever special syntax the particular variation provides.
The answer to the "intuitive" question is that different things are intuitive to different people. For example I can't imagine why so many light markups think _this_ is italic when to me that is so obviously underlined. /This/ is italic. In fact, for light markup (to reduce the misinterpretation problem mentioned in the previous paragraph) I prefer to be more explicit and have __underline__ and //italic// and **bold**. But that's just the problem, we all have different preferences.
Thankfully(???) there are so many "standard" light markup languages now that most of us can find a variation that suits us. There are a dozen or more fairly common Wiki variations, there are a few fairly common Markdown variations, there is AsciiDoc, there are variations of BB code like we use here on MobileRead ... and there are probably more I'm forgetting right now.
I think one of the things that makes AsciiDoc a bit different is AsciiDoctor that allows conversion to truly useful output formats (formats where the reader doesn't have to know whether _this_ is an underline or an italic because it will be shown visually). But a look through the AsciiDoc writing guide shows that once you go beyond simple requirements, things regress to what is essentially a coding/programming language, and you need access to the manual.
I once started to try and resolve this with a common intermediary language. One that would support two-way translation between itself and the many variations of Wiki and light-markup, including your own custom variations. Thus you could write with your own preferences and easily have your source convert to other people's variations (eg: write in AsciiDoc and send to someone that will view as MediaWiki). I do think it would be possible to get a good, if not perfect, result, but other priorities drew me away from that project.
So these days I am more interested in something that works with a widely accepted text formatting standard - usually HTML. Give me a styles-based HTML editor and I will be happy.
A styles-based HTML editor is yet another of my projects that I've not found time to pursue.
It seems to me that the problems raised by the introduction to AsciiDoc don't have to be solved by resorting to a text-programming language like AsciiDoc. They can be solved through guiding the user in the proper use of styles. A properly designed word processor will do that; it will let the user just start typing - and it will tell them that they are typing a plain text paragraph so they know to change it to a heading or whatever - and it will let the user change the appearance later using styles. HTML/CSS has most of what is needed to make this work, it just needs the right interface over top.
...
None of which helps you, rcentros. I was just rambling. If you find AsciiDos/AsciiDoctor seems to be working for you then of course you must follow to see where that takes you. Best of luck ... especially with hoping you can get the kids to read it
.