Re-design type definitions for attributes and event bodies

[lmolkova]

Attributes and event bodies can be of a complex types. With schema v2, we could have syntax like

types:
 - name: gen_ai.chat_message
   definition: todo

that's reusable inside other type definitions and as an attribute/event body type.

open-telemetry/semantic-conventions#2179 is an example where we define some types in JSON schema, but that doesn't look like the long term direction.

[jsuereth]

My thoughts here -

types:
  - name: my_custom_type
    enum:
       type: int   # This is the value type
       members:
         - id: one
           value: 1

So effectively, we have the following fields for a custom type:

• name: This is what gets used when referencing the type in an attribute. We reserve OTLP types like string, int, etc.
• Common attributes (like brief, deprecated, stability etc.)
• One of the following (these can be expanded over time):
  • enum: Defines an enumerated value.
    • type: can be either int or string
    • members: As existing enum definitions.
  • struct: Defines a simple structure (e.g. "location" of "lat"/"lon"). Maps to OTLP AnyValue.
  • (possibly) json: Reference a JSON schema which defines the shape of the type.

WDYT?

[lmolkova]

I love this proposal for simple types like enums!
When it comes to defining a type system for complex models, it can probably work similarly to event bodies, with a caveat that type definitions are reusable across telemetry items and maybe used as is or as types of nested objects. I still struggle with the idea of writing type system in yaml though. It's really easy to write code as code and we see examples (MCP, TypeSpec) where specs are written in plain TypeScript and are readable, automatable, and validatable.

Using yaml make sense since we already use it and we should definitely try to squeeze what we can out of it. But directionally, I'm not excited about building general-purpose type system in yaml.

PS: I've tried to reuse TypeSpec for semconv and failed - it's not designed for it as it is - we'd need to build our own tooling regardless.

[jsuereth]

Using yaml make sense since we already use it and we should definitely try to squeeze what we can out of it. But directionally, I'm not excited about building general-purpose type system in yaml.

Yes - This is why, eventually, I see writing a language + parser on the roadmap, but for now, let's do what we can with the time we can dedicate, and that means light-weight solutions on yaml or investigating one of these YAML alternative config languages.