Sampling SDK spec is outdated (and wrong by now)

[Oberon00]

See https://github.com/open-telemetry/opentelemetry-specification/blob/1729bc4337bdc1df83ff7eab53eb7405d6e75665/specification/trace/sdk.md#sampling

Sampling may be implemented on different stages of a trace collection. OpenTelemetry API defines a Sampler interface that can be used at instrumentation points by libraries to check the SamplingResult early and optimize the amount of telemetry that needs to be collected.

This is wrong, since samplers are an SDK concept and thus cannot (or at least should not) be used by instrumentations. Also, there is no mention of the TracerProvider having a sampler asssociated with it, or the tracer automatically checking the sampler when starting a span.

[cijothomas]

The Instrumentations/libraries can still use span.IsRecording() which is an API concept? (though IsRecording is set by the SDK based on sampling, but this instrumentation doesn't care how it was set)

[Oberon00]

They sure can use IsRecording. But I would expect the SDK spec to describe precisely that. Currently the connection between Sampler and Tracer(Provider) is not described at all. For example, if we want to describe what Java implements, we could add something like this to the spec:

When starting a span, the Tracer MUST query the Sampler that is assigned to the TracerProvider it was obtained from. If the samplers decision is NOT_RECORD, a Span with a valid trace and span ID generated/inherited as usual and IsRecording being false MUST be created and the SpanProcessors MUST NOT be notified for this Span, .

[cijothomas]

Got it.
+1 to having spec describing the sampling in more detail.

[jmacd]

Related: #625

[alolita]

Ack. @tedsuo will be providing an update in the Sampler SIG.

[alolita]

Based on the spec meeting discussion today, @Oberon00 please tag/assign me once you've created new issues that are more specific and closed this issue.

[Oberon00]

Closing this in favor of #781 and #782.