DUMBL
Duly Unambiguous Markup-Based Language(s)
For almost 2 years now, I’ve been on a deep-dive into parsing popular markup languages. I was trying to come understand was whys and hows that are relevant to the design of modern markups that grew to become popular. The goal, to design a harmonized parsing framework that is more human to reason with and deploy.

For the Reader
This is sort of my two-anniversary record of things related to parsing and markup. A year ago, I was not able to record such an account, and I had set out to try to change that, successfully.
This is not a technical document, and the reality is that DUMBL is not necessary something that you can use today, at least not from a contribution I am able to publish yet. This is more like a call for open-source collaboration to make that a possible contribution, and yes, we don’t have to stick with my decisions, only benefit from their difference in perspective.
You can deep-dive into code things. This write-up is meant to help others join those efforts. So please feel free to comment here or on GitHub.
I’m slowly picking up on errors, and with my best effort, it will likely always still happen, where I will accidentally flip things around — “unambiguous” where it should have read “ambiguous” — so thanks for working a bit harder while reading this.
Matter of Myths
You can say it’s NOT not politics!
Naturally, there is political weight behind the so called web-trifecta, ie html, css, and javascript, and family, json and wasm.
There is also certain appeal to other relatives, ie markdown and yaml, that offer overlapping and parallel features. The fact that they somehow shine across the same ecosystem, and yet we can trace their origins and growth to the open source sphere, we can certainly conclude one thing… Politics are far more complicated than parsing!
Politics or not, the bottom line is that while markdown and yaml parse at slightly longer cycles than their by-the-lobby offerings, but that is because they are actually more human than machine.
You can say it’s NOT not markup!
They are languages, and they have markup features, and so we can call them markup-based languages. So, while there are schools that will argue that they are markup, and at least few that will try to tell us they are not even markup-like, but most will fall amid the curve.
So what is markup exactly? Some will argue it is cut-and-dry, and some will say the jury is not even born yet, some even like to tell us that theirs ain’t. Let’s just say, people say whatever they feel sounds smart to saying at the time.
And so, my frame of “preference” would instead be to consider more broadly, languages that are at least markup-based. And that is when you have things that are neither proper text nor code, that happen to only be there for context and meaning about either, both or similar sequence.
Worth mentioning that I do not prefer to use strong words like data in my framing merely because in the right context, anything can be considered data.
And so by extension, opting for the markup-based framing is to hammer on the clear markup aspects involved, not to be offending anyone’s feelings.
You can say it’s NOT not human!
While the web-trifecta can be read by many people, it is still somewhat a myth of bias that all those are human-readable languages. Because most humans who are not “machine aware” of their imply, will not even know what to do when they show up on their screen by accident, as they do.
To try to be pragmatic, those are machine-readable languages that merely avoid characters that are not available on every keyboard. At least not on the ones that were available when they were designed. And so, I can at least by that say they are human-writable. As in, if you know what you want to write, and how to go about it, you can. You can do that. Even on mobile devices if you have the right gear. Sadly still, at least today, not as accessible as they were pre-mobile.
To try to be fair, human-readable is what markdown and yaml try to give us, and likely why they seem to have been predominantly reserved for meta and workflow aspects of our code-bases. And yet those can scale much much much better on the go.
So what should today’s notion of human-markup aspire to be? I say mobile, is flexible, is accessible, in high priority, not ambiguous, not dumb.
You can say it’s NOT not open-source!
It was sad to see over the years, how an idea as simple and straightforward as markdown sprouted many convoluted and conflicting “flavours”. All the politics and clocked-hours that made it so that one flavour became too popular, for arguably the wrong reasons.
This is at least one view of those who dig deep into parsing matters, that this particular flavour carries historical baggage that has left it, at least, more less human-friendly. And that is somewhat evident in the ignored outcries and confusion of the crowds.
Let’s not forget, open source is more about the form of collaboration — to not decree in profits — not source openly free of charge, from those who are of innovative spirit, to the benefit of those who are considered to have it entitled in their job description(s) — everything that a paid contribution could not be when open source became necessary — if that still means anything.
The Duly Unambiguous Markup-Based Language
Now that we covered some of the important background matters above, let’s shift to DUMBL matters — pronounced “dumb” just because it sounds funny.
The DUMBL Author
You are someone that is inclined to face the reality that you will be sometimes making mistakes. And so you are better off configuring your editor to make sure you end up with good clean markdown, a bit of html, maybe css, and understand the gist of yaml, json, along with some javascript goodness.
In that same spirit, you also appreciate that ambiguous code can sometimes clash with “opinions” and “preferences”, and when that is the case, you will find useful to keep an open mind, the ambiguities are “fact”.
- You can author DUMBL files that use the
.dumb,.dummy,.dmor.dumblextensions — and so you might want to consider a different name for yourREADMEfiles, or not. - You can also opt to use only
markdownparity features and in that sense you’d be better off using.md… etc. — and this can reasonably apply to the other types.
The DUMBL Parser
You are a program that parses a subset of all those languages and make no mistakes going about them. But you are also meant to make it possible for humans to figure out how they happened, if they want. Or to be able to make improvements when they do.
- You can switch modes based on the extension of a file, or based on syntax features that are explicit and unambiguous.
- You can use custom modes as well, and some of those are
dumbmodes that are ambiguous to reason about, so they are not always predictable and will likely entail certain costs and restrictions. - You use a parity document object model known as the DUM-DOM — pronounced “dumb dom” for consistency only — aka dummy DOM — a compositional dummy of sorts, that is very much like the real DOM but of a happier pursuit.
- You can use the real DOM all the same, but that can sometimes be unavailable, not to mention that it is relatively overkill and wasteful, so you still prefer the dummy.
- You are not offended when referred to as the DUMBLer — pronounced “dumb•ler” — also the common noun form “dumbler”.
- You can be fitted with extensions, which are referred to as a DUMBLing — pronounced “dumb•ling” — also the common noun form “dumbling”.
The DUMBL Document
You are an implicit notion that does not exist beyond the illusion, the file you are loaded from, the representational model, the rendered html, emulated terminal output, or an emitted string representation of sorts.
- You use some conventions of opinion that allow you to be flexible enough to port between similar formats, but sometimes those will not be wanted.
- You can entertain conventions of opinion when they are explicitly and unambiguously defined and have clean fallbacks.
Duly Unambiguous
So while this idea is still not completely realized, it has been proven over the years with solutions, but that always seem to fall short. Yet when they do, it is for the dumbest of reasons that are easier left in ambiguity, without due.
The problem with markup is that it is often times parsed with poorly formed opinions about ambiguity. Conventions, for some, that somehow never feel right for others. Preferences, for some, that always feel wrong for others.
Bad Tools… Not Fools
If we are honest, just because something has a more rational thought, it does not make it the correct thing, that others are expected to just take up and be grateful.
But for this notion of expression to pay off, it needs to be a real democracy.
You need to be able to give people tools to see your point, to appreciate the tradeoffs, and to be party to all matters of design. All people, all matters.
You also need to make sure that people don’t just feel like you are giving them tools to make your point more clear to them — certainly not just to end up ignoring good points made by your tools, all those manipulative things you think are not seen from the other side, to just be a
….
So that is the thing I like to call frictionless tools:
- Not for why you are right.
- Not for why they are wrong.
- Certainly not to just go ahead with your decree anyways when the tools show that they are right and you are wrong.
Where the goal of the tool is meant to be of pure reason and logic — where the context and meaning is always about equal opportunity for collaboration, recognition, and pay.
So it is about making the pipeline itself accessible and portable, which has been my focus for the past two years.
Bad Designs… Not Accommodations
While we are here, let’s revise how we look at accessibility. Because there is a vibe in the air these days to revise definitions of accessibility, and make them more inclusive.
Certainly, a very welcomed notion, but let’s make no mistake, these sort of things can cut both-way, and, historically, they often ended up just cut the same way after all.
If you are just there to make sure you are not excluded, just an ass, to those who don’t get it, and that is a fine thing to be, but, if you are riding the wave to make profit or make convention… a douche…
We’ve gone a long way since the times when I needed to pay out of my own pocket just to be able to use my metaphorical “left-handed” keyboard. But even today, people who are corporations are lining up devices of so called free-for-use accommodations but only in a profit-by-membership deal.
Say that convention is popularity, and so popularity made it so that some needed accommodations, and they are forced to either just pay or just pay and use it for free.
There are no conventions in the digital space of the handful of decades that would bare in any significance to the one that formed out of millenia… you cannot barter that people fade out of your world, it is not your world, you are just too lucky to be able… and yet so ignorant… to know that disability comes only from what we design, it is what we make, of our own, onto others.
The reality, those are accommodations to others’ biases. Those biases that get in the way of making all due time, although not necessarily with firm stance of any sort, to bother with becoming less ignorant. And, so long as it is okay to be blissfully assumed, by our privilege to ignorance, to have cost for those we design to exclude, so long as such progress will only come to be misused.
