Hi @lmolkova, we've discussed what changes to make based on your comments/questions.

We agree it makes sense to have url.full instead of the url.path and url.query. We think it's still important to have the components extracted out, so we'll have doc_id, target, url.full and the span name containing the path pattern with placeholders that will together provide a complete set of information on the api queried and with what data.
We've added a note that the server address and port are recommended.

We are also assuming from the spec that there will also be an http span.

Lastly, we've changed the db.statement to capture the request body for search-type queries. The list of Search APIs can be found here.

A config option could also be used that allows users to opt-in for capturing bodies of every request.

@lmolkova and @joaopgrassi I've updated the span name and attributes after a discussion with some more people internally.
There are two main changes:

• span name is the endpoint id of the request (the name field here, ex: search), rather than the http request method and request template (ex GET /{target}/_doc/{id}) . The Elasticsearch clients team said people would more likely want to identify ES requests by the endpoint id and that the request template would be less natural for them to see as a request identifier. We also have the http method anyway in the span attributes so we don't need to repeat it in the span name.
• the dynamic parts of the url path are set at span attributes like they are for http headers, as db.elasticsearch.path_parts.<key>

What do you think?

@open-telemetry/specs-semconv-maintainers could you please take a look? Thanks!

Generally looks good to me, but have some concerns around the implications of sensitive data handling.

I think @carlosalberto said in the SIG last night that he'd approve it and then we can merge.