Context
Today every (or almost every) language SIG generates semantic conventions from yaml files using Jinja templates.
Each SIG separates attributes based on the signal they appear on in one way or another:
- resource attributes vs all other attributes
- resource, spans, logs/events
While there are some deviations, most of jinja templates and codegen configurations are mostly consistent across SIGs.
Problem
We want attributes to be used across signals. E.g. user_agent.original is a span attribute on server and resource attribute in browser.
Code generation was already broken and is patched to keep the status quo until we find a better solution.
Questions to Otel SIGs:
How language SIGs see the 'perfect' outcome of code generation tooling?
- How do we group attributes? Do we group them at all or generate all in one class?
- How do we work with experimental vs stable attributes? Should we separate them into stable and preview artifacts?
- Do we want semconv libs to have consistent approach/api across languages?
- How do we guarantee that YAML refactoring or code generation tweaks would not change stable public API of semconv libs in the future even if we reconsider approach in the p1?
- Do we even want to ship stable semantic convention libraries in each language?
- anything else?
Language SIGs that generate semconv with Jinja templates:
- Java: separates resource vs all other attributes. @open-telemetry/java-maintainers
- JS: separates resource vs all other attributes @open-telemetry/javascript-maintainers
- Python: separates resource vs all other attributes @open-telemetry/python-maintainers
- .NET: separates resource vs trace @open-telemetry/dotnet-maintainers
- Go: separates resource, events, traces @open-telemetry/go-maintainers
- Collector: separates resources vs spans @open-telemetry/collector-maintainers
- Rust: separates resource vs all other @open-telemetry/rust-maintainers
- C++: separates resource vs all other attributes @open-telemetry/cpp-maintainers
- Erlang: separates resource, logs, traces @open-telemetry/erlang-maintainers
- Ruby: separates resource, traces @open-telemetry/ruby-maintainers
- PHP: separates resources vs all other @open-telemetry/php-maintainers
- Swift: separates resources vs all other @open-telemetry/swift-maintainers
Context
Today every (or almost every) language SIG generates semantic conventions from yaml files using Jinja templates.
Each SIG separates attributes based on the signal they appear on in one way or another:
While there are some deviations, most of jinja templates and codegen configurations are mostly consistent across SIGs.
Problem
We want attributes to be used across signals. E.g.
user_agent.originalis a span attribute on server and resource attribute in browser.Code generation was already broken and is patched to keep the status quo until we find a better solution.
Questions to Otel SIGs:
How language SIGs see the 'perfect' outcome of code generation tooling?
Language SIGs that generate semconv with Jinja templates: