Stabilize the schema file formats

[MrAlias]

Resolve #3844

Both of these files has not changed in two years and are broadly adopted in our semantic conventions. Given they are effectively stabilized as there is likely no desire to change these in any breaking way, make it official by stabilizing both.

[tigrannajaryan]

We are expecting significant new developments on the Schemas from this OTEP: open-telemetry/oteps#243

I think we need to evaluate the current schema file format from this OTEP's perspective before we mark format Stable.

My strong preference would be that any changes to the Schema file format that come from the OTEP are done in backward compatible way, by introducing new format versions. At the moment I don't see why it should not be possible.

@lquerel @jmacd @jsuereth any thoughts?

[MrAlias]

My strong preference would be that any changes to the Schema file format that come from the OTEP are done in backward compatible way, by introducing new format versions.

Agreed. I think this is true in a more general sense too. Any change submitted to these file formats needs to backwards compatible at this point given their wide adoption already in the semantic conventions.

I think the only question in resolving that OTEP is going to be if the new file format will be a minor or major version bump.

I don't think that will block stabilization of these existing file formats though.

[lquerel]

We are expecting significant new developments on the Schemas from this OTEP: open-telemetry/oteps#243

I think we need to evaluate the current schema file format from this OTEP's perspective before we mark format Stable.

My strong preference would be that any changes to the Schema file format that come from the OTEP are done in backward compatible way, by introducing new format versions. At the moment I don't see why it should not be possible.

@lquerel @jmacd @jsuereth any thoughts?

I do agree. With the modifications we plan to make to the existing Telemetry Schema format, we will need to introduce new format versions. It will also be beneficial to introduce a JSON Schema to facilitate the validation of this new format, as JSON Schema can validate both YAML and JSON. The same JSON Schema will also be useful for generating code to assist various telemetry schema consumers in easily parsing these files.

[tigrannajaryan]

@lquerel this is another topic that the Schema workgroup will need to figure out.

@MrAlias I assume you do not need this resolved urgently, right? Once open-telemetry/oteps#243 is merged there will be a workgroup that can deal with this.

[MrAlias]

I am hoping to have this merged sooner rather than latter. The Go SIG has many users that would like resource translations done for them but we cannot implement a solution in our stable package without this stabilizing.

I'm still failing to see where the conflict is coming from in stabilizing these two file formats.

If there are changes coming down the pipeline I expect they will be made in new file formats, not the existing ones. I would even go as far as saying that if someone recommended we change either of these file formats it should be blocked as it will break all of these.

[MrAlias]

I'm still failing to see where the conflict is coming from in stabilizing these two file formats.

If there are changes coming down the pipeline I expect they will be made in new file formats, not the existing ones. I would even go as far as saying that if someone recommended we change either of these file formats it should be blocked as it will break all of these.

@lquerel @tigrannajaryan: can you help me understand where the reluctance to approve this comes from?

[MrAlias]

Rereading the resource specification:

The resulting resource MUST have all attributes that are on any of the two input resources. If a key exists on both the old and updating resource, the value of the updating resource MUST be picked (even if the updated value is empty).

Proves our aspiration to provide a translation in the Go SIG frivolous.

Closing as this is no longer a pressing matter.