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

Proposal: Define semantic conventions in JSON/YAML #547

Closed
bogdandrutu opened this issue Apr 4, 2020 · 9 comments · Fixed by #571, #925, #926, #927 or #928
Closed

Proposal: Define semantic conventions in JSON/YAML #547

bogdandrutu opened this issue Apr 4, 2020 · 9 comments · Fixed by #571, #925, #926, #927 or #928
Labels
area:semantic-conventions Related to semantic conventions enhancement New feature or request priority:p2 Medium priority level release:required-for-ga Must be resolved before GA release, or nice to have before GA

Comments

@bogdandrutu
Copy link
Member

This is a proposal to define all semantic conventions in a format that can be automatically parse by every language and generate constants without having to manually sync their constant definitions with the markdown text in this repository:

  1. Move definitions in opentelemetry-semantic-conventions - languages can use git submodules to reference to that repository
  2. Specificantion will automatically generate tabels like https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/data-http.md#common-attributes when the git submodule is updated.
  3. Languages will automatically re-generate all constants when git submodule is updated.

This will allow us to keep consistency between languages and consistent description for every semantic convention defined.

Open questions:

  1. Which format to use JSON/YAML/etc.?
  2. Does anyone know about a tool to generate the markdown tables from the JSON? A simple tool can be written, but would like to avoid that.
  3. Should languages generate the constant code or read the files at runtime?
    • Personally I prefer generated code - fast initialization, compiler optimizations, etc.
@dyladan
Copy link
Member

dyladan commented Apr 4, 2020

Very interested in something like this

@carlosalberto
Copy link
Contributor

Sounds about the right time to implement this one. On the specific points, for 3) I'd also vow for generated code. No strong opinion/feedback on the other two.

@bogdandrutu
Copy link
Member Author

bogdandrutu commented Apr 4, 2020

Please +/- 1 the initial comment to count how many lgtms we have

@thisthat
Copy link
Member

thisthat commented Apr 6, 2020

I like the idea! I am currently working exactly on this based on a yaml representation. Our plan was to propose this once the code generation tool was implemented for multiple languages. We could propose a PR with our current yaml representation and start discussing if the model makes sense to everyone 😄

@bogdandrutu
Copy link
Member Author

@thisthat would be good to share why you decided on yaml in your experiment? May help us with the decision yaml vs json.

@Oberon00
Copy link
Member

Oberon00 commented Apr 6, 2020

I'd say JSON is not usable for human-written code, as it does not support comments. That's a killer-argument, as far as I'm concerned.

@thisthat
Copy link
Member

thisthat commented Apr 6, 2020

At the current status, it is more than just an experiment since we are close to having the code generation. To answer your question @bogdandrutu: both have the same expressiveness power, are well known by the community, and have great tooling support, but yaml is more compact as a representation and has the possibility to have comments that can aid the readability/maintainability of the semantic convention.

@tedsuo
Copy link
Contributor

tedsuo commented Apr 7, 2020

Guys this is a great opportunity to write our own config language and custom parser! j/k

@thisthat I'm curious about what metadata you would want included with each entry, if the purpose is for code generation.

An old (partial) implementation from the OpenTracing days: https://github.com/opentracing/specification/blob/master/semantic_conventions.yaml

@reyang reyang added area:semantic-conventions Related to semantic conventions enhancement New feature or request labels Jun 26, 2020
@reyang reyang added the release:required-for-ga Must be resolved before GA release, or nice to have before GA label Jul 6, 2020
@andrewhsu andrewhsu added this to Required for GA, needs action. Add label:release:required-for-ga to issues and PRs when moving them to this column. in GA Spec Burndown Jul 7, 2020
@bogdandrutu bogdandrutu added the priority:p2 Medium priority level label Jul 24, 2020
GA Spec Burndown automation moved this from Required for GA, needs action. Add label:release:required-for-ga to issues and PRs when moving them to this column. to Required for GA, done Aug 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment