Should it be considered “idiomatic KDL” to use node names as arbitrary keys?

[tmke8]

The following example KDL file is contained in this repository:

package {
    name kdl
    version "0.0.0"
    description "The kdl document language"
    authors "Kat Marchán <kzm@zkat.tech>"
    license-file LICENSE.md
    edition "2018"
}

dependencies {
    nom "6.0.1"
    thiserror "1.0.22"
}

Everything within package makes sense to me, but I was surprised to see how the dependencies are specified. The node names within dependencies are used as names of the packages. In XML, the analog would be to use custom tags for the dependencies. I would have expected it to be defined more like this:

dependencies {
    crate nom "6.0.1"
    crate thiserror "1.0.22"
}

(aside: in the case of Cargo.toml, you could actually convey other important information with the node name:

dependencies {
    // `registry` means the crate is found on crates.io or whatever registry is configured
    registry nom "6.0.1"
    // dependency from git
    git regex "https://github.com/rust-lang/regex.git" tag="1.10.3"
    registry hello_utils "0.1.0"
    // specify a path as well for `hello_utils` to use for local development
    path hello_utils "../hello_utils"
}

)

On reflection, the TOML syntax for Cargo.toml uses the same kind of slightly-surprising trick of using a table with arbitrary names for specifying the dependencies:

[dependencies]
nom = "6.0.1"
thiserror = "1.0.22"

However, with TOML you at least get the side benefit that this ensures that there are no duplicates in the crate names. KDL doesn't care whether you duplicate node names within dependencies, so we don't get that side benefit.

---

So, I lean towards not considering this pattern idiomatic KDL, but, well, you maybe shouldn't care what I think.

[zkat]

I find that this kind of thing depends a lot on the "DSL" you want to build, for things like this.

We already have an "idiomatic" node name for lists of nodes in a similar child context (-).

I'll note that the comparison with XML is missing three things here:

1. key-value pairs are notoriously painful to encode in XML. Having arbitrary node names in KDL is a great way to "solve" this problem.
2. Unlike XML, node names really can be any string at all in KDL, which makes them much more useful for arbitrary keys in map-like structures.
3. Other key/value systems, such as JSON, do not actually require keys to be unique. The JSON spec actually says "SHOULD" on this front, and ECMA-262 operates on "last-entry-wins", while some others throw an exception. I would expect KDL implementations to make similar choices, though I would recommend "last-entry-wins", to match the property behavior for nodes in KDL.

While I see what you're saying, I think it would be going a bit too far to expect 100% alignment with XML on this front.

[tabatkins]

Agreed. The DSL designer needs to be aware that using the node name as an arbitrary key will slightly restrict their ability to evolve things in the future, but that's perfectly reasonable in many designs, and KDL always offers the escape hatch of using a tag on DSL-predefined nodes if needed. Totally reasonable to do this sort of thing in many cases. (I do it in some of my DSLs.)

[zkat]

also worth noting: the usage of - only really applies if your "list" is bound to use something other than strings. If you're sure you'll only ever have strings as child "values", you can just use node names period. I think it's kind of a neat thing:

my-list {
  foo
  bar
  baz
}