Guidance on product/project name inside attribute/metric name

[lmolkova]

We should provide a guidance on product/project name being fully qualified (or not). We should keep the same pattern in different semconvs.
Examples of inconsistencies:

• db.cosmosdb (Azure), db.dynamodb (AWS), db.couchdb (under Apache umbrella), db.spanner (GCP), db2 (IBM), hanadb (SAP HANA) etc and corresponding values in the db.system enum
• we also have aws_sqs, gcp_pubsub, azure_servicebus in the messaging.system enum

We should provide a guidance on how to represent multiple words:

• lowercase product name (couchdb) (#Codegen: proper casing for multiword attribute/metric names #599)
• multiple namespaces vs single namespace (e.g. messaging.aws_sqs.destination.custom_attr vs messaging.aws.sqs.destination.custom_attr)
• acronyms/abbreviations guidance (Add guidance on abbreviation usage in semantic attribute names #602)

We should require consistency across signals:

• Redis can be used as messaging system and should have exactly the same representation in db.system and messaging.system
• If Azure Service Bus is instrumented on the service side to report telemetry to end users, it should use the same value in resource attributes (Define cloud.platform and/or rename it #609)

Misc discrepancies:

• mssqlcompact (Microsoft SQL Server Compact) should probably become mssql_compact

[Update]
Other attributes that have the same problem:

• cloud.platform

[alanwest]

With regards to representing multiple words, can a product's branding provide a guide? For example, use dynamodb, couchdb, and cosmos_db because they are respectively branded DynamoDB, CouchDB, and Cosmos DB.

[trask]

It would be nice if whatever the enum is, e.g. cosmosdb, that is also the namespace, e.g. db.cosmosdb.*, for product-specific attributes

[trask]

do we think we need mssqlcompact? that doesn't seem like something we'd necessarily know from the client side, and on the server side it could potentially be a resource attribute describing the "edition"

[KalleOlaviNiemitalo]

SQL Server Compact runs in-process rather than as a network service, so yes, the application should know it's using that.
It's no longer supported by Microsoft, but open-telemetry/opentelemetry-specification#3105 shows it's still used.

[lmolkova]

Based on the messaging SIG discussion on 6/13, none of the controversial systems are part of the initial stability (kafka + RabbitMQ), so removing the stability blocker label.