Opentelemetry-specification: Rename SpanReference to SpanContext (revert #1075)

[carlosalberto]

What are you trying to achieve?

Revert #1075 after it was badly received in the actual implementations. Overall, the reasons behind going back to SpanContext are:

• SpanContext is an already very well known term.
• SpanReference may make people think of pointers/references.
• SpanReference includes additional information to Spans, such as tracestate.
• Too late in the game to make this change overall, as well as the lack of a true perfect solution.

For this change, we will actually expect more than the usual reviews, in order to verify with SIG maintainers/approvers this is a good thing.

[jmacd]

This was discussed extensively in yesterday's Spec SIG (APAC) call. We found among the group general consensus that SpanContext is not a perfect term, but that the cost of changing from SpanContext (which is well established) is too high to justify the change.

[marcingrzejszczak]

I wasn't there at the meeting and I don't know if the discussion is closed or not but in Brave the term is TraceContext and it's also well established :shrug:

[tsloughter]

As I mentioned in the meeting, while I think SpanReference (or similar so it isn't confusing to those users of languages with references) would be an improvement, the use of SpanContext is everywhere, code and docs and blogs, it is just simpler to not change unless there is a really really good reason.

Also a good point that it isn't a reference to a Span, it contains trace state too. But it also "isn't" a TraceContext since it is the necessary identities for a particular Span plus the Trace state.

So defining the term really well is the best way forward, even if a term could be come up with that perfectly states what it is -- like TracePropagatationIdentifiers :)

[reyang]

I vote for keeping SpanContext. SpanReference is a very confusing term for both C# (.NET) and C++.

[Oberon00]

SpanContext is also a very confusing term because it is not the Context of a Span. I think reference is less so (e.g. there is also https://docs.microsoft.com/en-us/dotnet/api/system.windows.markup.reference or https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.xml.reference). The only argument for reverting that I buy is that SpanContext is already well-known. If we introduced the concept today, I would strongly object against SpanContext.

[yurishkuro]

+1 to go back to SpanContext.