Mark telemetry schema readme stable.

[jsuereth]

Part of unblocking #3219

Changes

Mark the telemetry schema README as stable.

Reasoning:

• The README outlines a process for including schema files and defining transformations. OTEL has been following the process laid out for some time.
• Most of the readme is informational/guidance.
• The "meat" of stability for schemas is in the file format. These are still experimental, as we tune/figure out the right set of transformations. Any concerns around "right set of transformations" should be discussed when stabilizing the file format, given the current structure of the specification.
• Significant components of semantic convention and the specification hinge on the existence of Schema files and the outlined process in this readme.

[reyang]

Do we consider this README part of the spec or not?

If it's not part of spec, it shouldn't have "Stable" tag. (e.g. similar to https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/README.md)

If it is part of the spec, we need to fix the wording (e.g. s/should/SHOULD).

[MrAlias]

Do we consider this README part of the spec or not?

If it's not part of spec, it shouldn't have "Stable" tag. (e.g. similar to https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/README.md)

If it is part of the spec, we need to fix the wording (e.g. s/should/SHOULD).

Good point. I had considered these README to be non-spec. I haven't been reviewing them for requirements we need to implement.

[tigrannajaryan]

Do we consider this README part of the spec or not?

This is a good question. I would definitely consider some parts to be a spec. For example "How Schemas Work" contains a lot of normative language. Similarly "Schema URL" section is precise and is a spec.

As opposed to that "Use Cases" are examples that are not a spec.

[carlosalberto]

I would definitely consider some parts to be a spec.

Agreed. Alternatively we can 'extract' such parts and put them into their own document. Fine by me either way.

[jsuereth]

So I've updated the normative wording. I think there's a few normative phrases in this document that are crucial to stability and that we've been enforcing:

• We will provide documentation of available schema transforms and limit ourselves to those available.
• Schema URLs must be backed by real files that can be downloaded.

The other should/musts I found were demonstrative, not normative so I've modified them.

PTAL