I've long made half-hearted stabs at creating what I call "NFML", a.k.a. "No Markup Language". My vision is incredibly similar to this, so I wish you luck! I believe the future resembles KDL.
The KDL Document Language
31–40 of 64 posts
Re: The KDL Document Language
#32What's the use case of this? It's for configs, documents or what?
Re: The KDL Document Language
#33What's the use case of this? It's for configs, documents or what?
I think anything you would normally write a schema for, and edit by hand. It does actually come with a schema language too, embedded in KDL, based on JSON-schema. I think it would be a great syntax for something like CSL (Citation Style Language, something I work with); not a document, no actual content, but free-flowing, recursive, needs a schema, and is edited by non-programmers. There's a lot of talk in CSL-land about graphical editors because XML is just too hard, but graphical editors are also too much effort to build. Someone once suggested based on general facts (lighter, etc) about JSON that CSL should switch input language to JSON -- that would have been a disaster, JSON is terrible for this. (And the CSL project wouldn't change its spec dramatically and unnecessarily.) But KDL seems good for that kind of thing.
Unfortunately I don't quite see it as a replacement for Jsonnet (or Dhall, etc) in terms of writing extremely laborious Kubernetes/Terraform/etc config by hand. It doesn't seem very easy to embed a functional KDL-generating language in KDL. I sat down and tried to imagine what this would be like and couldn't make it connect. Maybe someone else can give this a shot, there are devops folks out there that need saving from YAML. Part of the problem for KDL as a replacement for these is that its mapping to JSON/YAML is a bit awkward, whereas XML is actually pretty close. That's presumably why Kat called it their Document Language. So I expect if it catches on it will be in greenfield projects or XML revamps.
Re: The KDL Document Language
#34They mention xml quite early but bury how you’d do markup inside a text. Basically you can’t do it, but there is a convention to work around it. > If the element contains mixed text and element children, the text can be encoded as a KDL node with the name - with a single string unnamed argument. For example, the XML some bold text > can be encoded as span { - "some "; b "bold"; - " text" }.
I'm pretty sure that's invalid KDL, despite appearing in the XML-in-KDL document. Both the grammar and kdl-rs appear to require a trailing semicolon before the close brace. I think this might be a bug in one of the specs.
Re: The KDL Document Language
#35Earlier quoted context omitted.
When my projects are posted publicly, I like attaboys, but I need constructive criticism. Asking pointed questions and questioning purported inconsistencies is not complaining.
Criticism given by those that do not align with the core goals/userbase of a project is not constructive. Giving criticism on something you don't intend to/wouldn't use is just complaining.
I disagree, there's always the chance that there is a nugget of useful knowledge in there. I'd rather go through 100s of criticisms than miss it.
Re: The KDL Document Language
#36Is this related to https://kaitai.io/ ?
[deleted]
Re: The KDL Document Language
#37> The language is based on SDLang
Aha, cute pun! :)
and the lang itself looks quite nice tbh
Re: The KDL Document Language
#38Hi! I'm the author of the Java KDL library, https://github.com/hkolbeck/kdl4j . I'm currently overwhelmed by other things and unable to do the work to get it up to the 1.0.0 spec. I'm looking for folks willing to help me. DM me on Twitter at the same name if you're interested.
thank you for this very cool effort; what if the folks able to help are those who shun twitter?
(of the strong programmers i know, each refuses to have anything to do with twitter.)
Re: The KDL Document Language
#39Hmm... Not really sure I get what problem this schema is the best solution for. It seems like the author was more interested in implementing a model they felt was more conceptually sound than other solutions, but aren't solving any significant problems, and don't seem to have any big functional improvements over more established contenders. Just going through the section for why they think it beats YAML: > YAML can b…
> It seems like it adds significant complexity over YAML to mitigate abuse of YAML
On the complexity axis I think you're talking about, yes, having clear scopes and no ambiguity about whether something is a string means there are more bits of syntax to type, but I don't think that adds complexity. JSON has more curly braces and quotes but it is a much simpler and much more reliable format than YAML. KDL is the same.
KDL does not "add significant complexity over YAML" in really any sense. The KDL specification is 1/10th the size of YAML's. Being extraordinarily complex and impossible to fully implement is is what YAML is famous for.[0] Asking people to do a better job writing YAML is a tough ask when even computers can barely do it correctly.
Re: The KDL Document Language
#40Earlier quoted context omitted.
Criticism given by those that do not align with the core goals/userbase of a project is not constructive. Giving criticism on something you don't intend to/wouldn't use is just complaining.
I disagree, there's always the chance that there is a nugget of useful knowledge in there. I'd rather go through 100s of criticisms than miss it.
For some perspective, this HN thread is much, much better than the Reddit post from yesterday. Sure, there were a couple of good points hidden in the rubble, but lordy it was bad. Cruel, even. The main author has taken a break (and fair enough) so you probably won't see them around today.