Add typed spans working document

[danielkhan]

No description provided.

[bogdandrutu]

@danielkhan thanks for the PR, you need to sign the CLA.

[flands]

These seems contrary to OpenTracing. The mandatory field should be db.type. Why db.instance?

[danielkhan]

Maybe this was a mistake in reading the spec. Looking at https://github.com/opentracing/specification/blob/master/semantic_conventions.md#database-client-calls it seems as if both should be required. Would you agree?

[flands]

If required, all options should be explicitly defined. Why are any of these required?

[danielkhan]

They are required to map them to a concrete instance in a model that might be external to OpenTelemetry.

[danielkhan]

@danielkhan thanks for the PR, you need to sign the CLA.

Yes we are waiting for our legal team to take care of that.

[tylerbenson]

Can anyone offer insight as to how we expect this would be implemented? For example, would there be many different sub-classes of Span, each with different sets of fields? Or perhaps a "typed attribute" field inside Span that these would be set on?

[discostu105]

@tylerbenson IMHO this work should be split in two parts.

1: Just documentation of what attributes exist and which are supposed to be on certain kinds (more like OT "semantic conventions", but with the canonical type notion). Not technically binding, but rather recommendations. Why? It has value both on implementing instrumentation as well as on interpreting data (analytics backend).

2: Typed spans API. This is a different discussion (we should do separately :)). IMHO we should keep generic span classes, with generic span attributes. But we could add typed "Builder" classes that would help a user to set the correct attributes (via dedicated API's for each attribute).

[SergeyKanzhelev]

@danielkhan I think it's a good idea to merge this document in and then start transferring pieces of it to the folder outside the work_in_progress folder. We started by copying open census and open tracing documents into subfolders of this folder and when specific item is described in the document like https://github.com/open-telemetry/opentelemetry-specification/blob/master/work_in_progress/gRPC/gRPC.md or https://github.com/open-telemetry/opentelemetry-specification/blob/master/work_in_progress/database/database.md - those attributes are removed from the originally copied specs.

Does this approach make sense for you?

[danielkhan]

@danielkhan I think it's a good idea to merge this document in and then start transferring pieces of it to the folder outside the work_in_progress folder.
[...]
Does this approach make sense for you?

Absolutely. That sounds like a good approach to get the ball rolling, @SergeyKanzhelev

[SergeyKanzhelev]

I'm going to merge it as this is work in progress. Basically an accumulation of many documents. Documents that will require a bigger consensus will be placed outside of this folder.

[SergeyKanzhelev]

@tylerbenson IMHO this work should be split into two parts.

@discostu105 perhaps there should be the separate issues for those separate discussions than