Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roll up #65

Merged
merged 15 commits into from
Oct 31, 2024
Merged

Roll up #65

merged 15 commits into from
Oct 31, 2024

Conversation

cabo
Copy link
Collaborator

@cabo cabo commented Aug 24, 2024

Pull in Section 8 of RFC 8949 and Appendix G of RFC 8610 so we indeed have a single document defining EDN (minus EDN extensions).

Work in progress.

This is mostly unedited, just making sure the document builds
(and removing 8610 § G.4, which already was edited out earlier).
CBOR data items.
For instance, {{YAML}} {{-yaml-media-type}} is able to represent most CBOR
data items, possibly requiring use of YAML's extension points.
YAML does not provide certain features that can be useful with tools
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it might be good to name these features or omit this

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done (not all features, just two examples).

@rohanmahy
Copy link

rohanmahy commented Aug 25, 2024

Hi, Thank you Carsten for getting the ball rolling on this. I have not had time go over this in detail yet, but I think getting consensus on an outline/document flow is great. I was pleased with the discussion between you and Joe H on that topic and feel that that work is yielding good results.

On a separate note, I think a lot of the material in the Abstract is more appropriate in the Introduction. For the Abstract, I propose the following radically shorter text:

"The Compact Binary Object Representation (CBOR) specification includes an informal description of a diagnostic notation, which was augmented over time and is now know as Extended Diagnostic Notation (EDN). This document consolidates previous descriptions of EDN into a formal specification, preserves backwards compatibility with most instance documents, adds requested features which are already implemented, and introduces a limited extensibility mechanism."

Then I think the Introduction would be best split into the material that explains the goals of EDN, how it is related to CBOR, where it is used, that JSON is a strict subset, and summarizes the features in the current incarnation. I would put the "how we got here" material into an "Historical Background" subsection of the Introduction.

I hope this helps.
thanks,
-rohan

@cabo
Copy link
Collaborator Author

cabo commented Aug 26, 2024

On a separate note, [...]

Thank you for this feedback.

I generally write introductory material twice:

  • Once to make up my mind what I want to write
  • Once after I have written the main document and know what the introductory material should have said.

We aren't at the second point yet.

I opened issue #66 and #67 so we don't forget this when we get there.

@cabo cabo marked this pull request as ready for review October 31, 2024 15:30
@cabo cabo merged commit 222fa35 into main Oct 31, 2024
0 of 2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants