CBOR ⇔ YAML mappings

[BurtHarris]

Credits where credit due:

• JavaScript: was invented in 1995 by Brendan Eich.
• YAML: was proposed in 2001 by Oren Ben-Kiki, Clark Evans, and Brian Ingerson.
• JSON: was introduced in 2001 by Douglas Crockford.
• MessagePack: was introduced 2012 by Sadayuki Furuhashi
• CBOR: was introduced in 2013 by Carson Borman

Thanks guys.

---

I propose we discuss ideas regarding YAML tags to produce a formal mapping with Compact Binary Object Representation, (CBOR RFC 8949) and related RFCs, for example:

• RFC 8152 defines CBOR Web Token (CWT), which is a compact format for representing claims to be transferred between two parties.
• RFC 8392 defines CBOR Object Signing and Encryption (COSE), which is a set of specifications for creating and processing secure messages using CBOR .
• RFC 8610 defines Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structure
• RFC 8747 defines CBOR Encoding of Data Modeled with YANG .

TLDR

Continues Issue #7

CBOR (Concise Binary Object Representation) originally published as RFC 7049 in 2013 by Carsten Bormann (@cabo). I asked Carsten about this some time ago, and he clearly was knowledgeable about YAML.

CBOR is a binary format that is designed to be compact and efficient. CBOR implementations tend to be very fast and have a developer-friendly API .

On the other hand, YAML is a human-readable serialization format that is designed to be easy to read and write. [It is often used for configuration files and data exchange between different programming languages (https://discourse.mc-stan.org/t/notes-on-stan-output-serialization-options-yaml-protobuf-avro-cbor/12837)[1] YAML supports complex data structures such as lists, maps, and nested structures .

Importantly CBOR and YAML are both extensible through the use of tags that express extensible data types! While there are some semantic differences between tags in these two standards, I think they can be identified and mitigated due to the inherent flexibility of YAML; it might take some outside-the-box thinking.

Given the amazing versatility of @eemei/yaml, I think this would be the perfect place to take advantage of the common heritage between these, which traces back to JavaScript and JSON. Also, I note that while this common heritage linking back to JavaScript was based on an now long-past standard for the language, which has since been substantially improved. In the path from then to now, some terminology differences have crept into both YAML and CBOR/CDDL which complicate such discussions.

[BurtHarris]

Relationship to CBOR Diagnostic Notation

https://www.rfc-editor.org/rfc/rfc8949.html#name-diagnostic-notation discusses a text based format for CBOR to facilitate documentation and discussion. It borrows from JSON syntax but extends JSON in several ways that are not at all YAMLish.

NOTE: The diagnostic format was not meant to be parsed.

A standardized, bidirectional mapping between YAML and CBOR might be valuable as a alternate diagnostic notation. I will try to give examples in future posts.

I note that there is also an Extended Diagnostic Notation described in Appendix G of RFC8610. Frankly, I'm still trying to understand CDDL to my satisfaction, so I will not comment further.

[BurtHarris]

Tim Berners-Lee regretted one small thing

According to the New York Times, the web's inventor, when asked "Any regrets?" had one:

Mr. Berners-Lee smiled and admitted he might make one change — a small one. He would get rid of the double slash “//” after the “http:” in Web addresses.

The double slash, though a programming convention at the time, turned out to not be really necessary, Mr. Berners-Lee explained. Look at all the paper and trees, he said, that could have been saved if people had not had to write or type out those slashes on paper over the years — not to mention the human labor and time spent typing those two keystrokes countless millions of times in browser address boxes.

The times however failed to mention the W3Cs mitigation to Tim's concern, CURIE Syntax 1.0. CURIES (Compact URIs) are an extension of the QNAME concept, which was found to be overly restrictive. Unfortunately, all that happened after YAML's creation. There exists however so much flexibility in YAML's conservative definition that might allow the use of CURIEs in YAML...

[BurtHarris]

Example CURIEs

All of the following are syntactically valid Compact URIs. They take advantage of the fact that the part after the colon no longer needs to conform to the rules for XML element names, making them much more flexible than regular URIs.

• cbor:1
• google:xforms+or+'xml+forms'
• home:#start
• joseki:

CBOR uses binary values as tags, not strings. Low-numbered CBOR tags are stored in a particularly compact format as a prefix on a payload value that follows the tag. Some CBOR tags are predefined, for example CBOR tag 1 is defined to mean the following number represents a Unix time.

So hopefully some of you see where I'm going here.

now: !cbor!1 1686419618

Could be used to encode the now time 2023-06-10T17:53:38+00:00, including preserving the intent that it be represented using the Unix time model; mapped to/from the CBOR binary representation.

[cabo]

On 2023-06-10, at 18:20, Burt Harris ***@***.***> wrote: = Relationship to CBOR Diagnostic Notation https://www.rfc-editor.org/rfc/rfc8949.html#name-diagnostic-notation discusses a text based format for CBOR to facilitate documentation and discussion. This format **was not meant to be parsed **. It borrows from JSON syntax but extends JSON in several ways that are not at all YAMLish.

Indeed. A binary format needs to come with a text-based representation that everyone will recognize and understand, for use on whiteboards as well as on . Therefore we standardized such a notation right away with CBOR. At the time (2013 in RFC 7049), it seemed easier to attain consensus to start with JSON and add a few extensions. We then added a few convenience features (“extended diagnostic notation”, EDN) in 2019 (RFC 8610). A few more are in the pipeline [1]. We found it useful to mechanically check examples in RFCs that employ diagnostic notation, so there are now parsers for it [2]. (E)DN is still not something that we would use for the actual interchange of data.

A standardized, bidirectional mapping between YAML and CBOR might be valuable as a better diagnostic notation. I will try to give examples in future posts.

In my personal editor configuration, CBOR files are opened by converting them to YAML [3] (and converting back to CBOR on writing). This works great for me (and YAML is my go-to format for a human-processable form of JSON). YAML may however not be for everyone [4]. My biggest practical problem is that binary data are by default base64-encoded in YAML; that can be very jarring (or great — the CBOR data simply doesn’t have any indication which would be the best textual representation). Until now an obstacle for using YAML as a textual notation for CBOR was that there was no IETF document we could point to; this of course is being fixed now (although the media-type registration does not give me an actual definition of YAML). I think we will continue to use CBOR (extended) diagnostic notation for examples in RFCs. Grüße, Carsten [1]: https://www.ietf.org/archive/id/draft-bormann-cbor-edn-literals-02.html [2]: https://github.com/cabo/cbor-diag [3]: cbor2yaml.rb/yaml2cbor.br in [2] [4]: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell