Composable sampler naming conventions

[jmacd]

What are you trying to achieve?

The prototype for Java consistent probability sampling package,
https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/consistent-sampling,
has names that conflict with the new specification.

Discussed in Slack, written by @trentm

New implementations of the composite samplers should bias to the class/interface naming in the spec (ComposableAlwaysOn, ComposableTraceIDRatioBased, et al) over the naming in the OTEP and Java impl (ConsistentAlwaysOn, ConsistentFixedThreshold), right?

Hi. I'm reviewing a PR to add support for (a subset) of the sampling support documented at https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling/ (i.e. OTEP 250) for OTel JS: open-telemetry/opentelemetry-js#5839
and I have some general questions on the spec/OTEPs and guidance for implementations.
(This PR for OTel JS is related to a similar one adding support to OTel Python: open-telemetry/opentelemetry-python#4714)
Currently these implementations were based on the Java implementation at https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/consistent-sampling/src/main/java/io/opentelemetry/contrib/sampler/consistent56
From reading the OTEPs and the spec text, I notice that there are differences in the naming used for classes:
OTEP 250 and the Java impl: ConsistentAlwaysOff, ConsistentRuleBased, ConsistentParentBased, etc.
The spec: ComposableAlwaysOn, ComposableTraceIDRatioBased, ComposableParentThreshold, etc.
I didn't see anywhere in the spec PR where the name differences were discussed.
I gather that new implementations should prefer the naming in the spec, right?
Looking at the jmacd's Go and Rust implementations, I see that they tend towards the spec naming.

What did you expect to see?

I @jmacd do not strongly believe that all SDKs need the same exact names. "Composable" and "Consistent" are both acceptable, IMO.

cc/ @trentm

[carlosalberto]

So I did a quick review and indeed, names have slightly changed. So the short answer is that the Specification names should be used.

The long answer is that OTEPs are:

documents of intent. They become requirements only after their contents have been integrated into the actual Specification.

[carlosalberto]

On the names themselves, these new set of samplers are still in development, and we can still change their names if needed. I agree with @jmacd on

do not strongly believe that all SDKs need the same exact names. "Composable" and "Consistent" are both acceptable

But we can discuss that if needed. Wdyt @trentm ?

[trentm]

do not strongly believe that all SDKs need the same exact names.

Sounds good to me. It is helpful to have this mentioned here for reference. Thanks.

[trentm]

I would guess that eventual integration of these newer samplers into the OTel configuration data model schema would enshrine one set of names.