There are a few cases where we're making a conscious choice to divert from the KDL spec. These should be documented near the top. Currently this includes:

• Many entities in KDL are defined in terms of code points (for instance, KDL identifiers are made up of "any code point except for ...". Rust strings and char are sequences of Unicode Scalar Values, rather than Code Points. A Scalar Value is a slight subset of a Code Point that just excludes low and high surrogates. In practice we don't expect this will cause any issues.
• KDL calls for duplicate property keys to be last-key-wins, and other keys ignored. We instead will use the ordinary serde map handling for these cases (ie, next_key_seed will always return the next key, without any consideration for duplicates).We prefer the flexibility offered by this, since Deserialize types have the opportunity to define their own behavior when receiving duplicate keys. HashMap, for instance, uses the last-key-wins strategy, while structs with derive(Deserialize) will fail with an error on a duplicate key.

KDL 2.0.0-draft.3 is now generally available (kdl-org/kdl#286), and with it, we've decided to encourage existing implementations to start working towards 2.0 support and send feedback and suggestions for anything you might run into, so I'm making this tracking issue. :)

Implement $kaydle::name magic, for getting the node name in an anonymous node context

Currently we throw away error locations in pretty much all cases. Variants in the Error enum should retain some useful context about what went wrong.

We need to support /- comments.

(Sorry for the meme-y issue title, I couldn't resist)

https://github.com/CAD97/serde-kdl

I'm also interested in using KDL in some projects, so I went and wrote some code before I saw that you had some progress on deserialization. Interestingly, I started with a serializer (to help develop my vision of SiK), so no implementation work's technically been duplicated yet.

I don't think my vision of SiK (Serde-in-KDL, a la JiK and XiK) meshes with your vision, but you might still be able to take advantage of some of my serialization machinery, which is heavily inspired by serde_json's.

I'd prefer not splitting the ecosystem before it's even started on how to map the serde data model into KDL, so maybe it's worth discussing a shared vision for SiK, maybe even getting Kat to weigh in. I'm available mostly whenever wherever (CAD#8720 if you want to ping me on the Rust discord, CAD97 on urlo); I could even pop into a stream if you'd like that.

I think Serde-in-KDL is ideally something that kdl-org might want to own/specify and we should both target, even if we end up making separate implementations of it.

We need to support type annotations. In general we rely on serde to drive the type interpretations, so for 1.0 my intent is only to parse and discard them. Future support post 1.0 should include:

• Smarter number parsing (use the type annotation rather than formatting inference to pick between i64 / u64 / f64
• Add a kaydle magic to support storing them somewhere.

We should implement the various methods in de::Error to pick out more specific error variants than Custom, where applicable.

I'm trying parse follow txt, but get

called `Result::unwrap()` on an `Err` value: TypeNameMismatch { node_name: "server_name", type_name: "ServerBlock" }

reproduce text

worker_processes  1
events {
    worker_connections  1024
}


http {
    include       "mime.types"
    server {
        server_name  "localhost"
        location "/" {
            root   "html"
            index  "index.html" "index.htm"
        }
        location "/" {
            root   "html"
            index  "index.html" "index.htm"
        }
        
    }
    server {
        server_name  "localhost"
        location "/" {
            root   "html"
            index  "index.html" "index.htm"
        }
        location "/" {
            root   "html"
            index  "index.html" "index.htm"
        }
        
    }

}

Currently, identifiers only accept alphanumerics. They need to be updated to match the spec.

Currently we discard all information from parse errors. Use nom-supreme::final-parser utilities to convert nom errors into a more useful error message. Use ErrorTree for context retention.