Canonical type field for spans

[SergeyKanzhelev]

See discussion: #14 (comment)

The proposal is to have a strongly-typed field on a span that will define its type and ultimately - the set of attributed one should expect to see on it and interpret.

The alternative is to have a predefined attribute name for this type.

This change should be driven by scenarios we plan to enable in OpenTelemetry that will use this field. For instance, a strongly typed field can be justified by a scenario like metrics extraction from the specific span types.

[danielkhan]

+1 on a strongly typed field like an enum.

[Oberon00]

Maybe related: #271

[jmacd]

Discussed in the 0.3 triage party. Sometimes a span can satisfy more than one "type". Do we believe that span type is always unique?

[dyladan]

can you provide an example of a span with more than one type?

[jmacd]

I believe the discussion hypothesized a span that was both an HTTP server span and a DB client span. You could use multiple spans to reflect this reality, but it sometimes is not a good use of resources to make two spans when one will do.

[pauldraper]

You could use multiple spans to reflect this reality, but it sometimes is not a good use of resources to make two spans when one will do.

Too much has been lost to combine everything in one span.

A span that is both an HTTP server span and a DB client span will have a bewildering array of attributes.

Imagine the kinds of horrible programs you'd get trying to cut down call stack size by a few.

[SergeyKanzhelev]

this issue was opened long ago with the theoretic scenario in mind. Let's close and reopen if there is somebody who is willing to drive this discussion forward.