What capitalization of field names to use for trace context in non-OTLP Log Formats

[tigrannajaryan]

Trace Context in non-OTLP Log Formats uses snake case for field names currently: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/compatibility/logging_trace_context.md

The OTLP/JSON which is another format where field names are recorded as text uses camelCase (traceId, spanId).

Should we change recommendation for non-OTLP formats to use use camelCase?

@open-telemetry/specs-logs-approvers @open-telemetry/specs-approvers what do you think?

Relation PR that previously suggested yet another approach (using dots to match ECS): #3469

[trask]

@open-telemetry/specs-logs-approvers @open-telemetry/specs-approvers now that logs are stable, it would be great if we can get consensus on this

In particular, it looks like Java and Go may already be using different field names: open-telemetry/opentelemetry-java#5528

Also, see a third option which would align with ECS: #3303 (cc @AlexanderWert @ruflin from ECS perspective)

[ruflin]

On my end, I would expect that semconv uses the same convention for all signals and fields. For things like http.methods.* (open-telemetry/semantic-conventions#17) it seems the dot notation was adopted. This also aligns well with ECS. But it seems this conflicts with some existing json logging (https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/specification.md) as it was noted in the PR from @trask

I assume because of backward compatibility, some fields will keep existing that don't follow the general convention. But is there a decision made on what the convention is? My current assumption is it is dot notation with _, not camelCase which ECS uses.

[tigrannajaryan]

Are you proposing to use trace.id? Dots are for namespace separation in semconv. trace_id is a field name in log data model, it is not an "id" field in the "trace" namespace, so we shouldn't use a dot to separate "trace" from "id". Underscore is used in semconv to separate words in the name, which is what we are doing in trace_id.

[jack-berg]

Something to think about:

While its true that OTLP/JSON converts keys to lowerCamelCase, that applies to the field names - the names of attributes are left untouched. So the question seems to be are trace_id / span_id closer to field names or attribute names? If we think they're closer to attribute names, we SHOULD leave them untouched. If we think they're closer to field names, we might consider switching to lowerCamelCase. But we also shouldn't feel obligated to adopt the same rules as OTLP/JSON for something that isn't related.

I'd argue trace_id / span_id ARE field names since they appear as top level fields on LogRecord. However, the changing the case is disruptive, and the benefit of alignment with the unrelated OTLP/JSON format does not justify the disruption. Therefore, I'm in favor of keeping the trace_id / span_id the way they are.

[tigrannajaryan]

I agree with @jack-berg's arguments. I don't see strong enough arguments to make a disruptive change.

[tigrannajaryan]

No other new arguments brought up. Closing, will keep the spec as is.