One problem is that renaming with a prefix is not allowed by policy, as a result I get the following error when trying to validate policy:

Violation: Attribute 'code.column' name is used as a namespace in the following attributes '["code.column.number"]'.
  - Category         : naming_collision
  - Type             : semconv_attribute
  - SemConv group    :
  - SemConv attribute: code.column
  - Provenance: /home/weaver/source

Violation: Attribute 'code.function' name is used as a namespace in the following attributes '["code.function.name"]'.
  - Category         : naming_collision
  - Type             : semconv_attribute
  - SemConv group    :
  - SemConv attribute: code.function
  - Provenance: /home/weaver/source

I don't know where does this restriction comes from, is it related to the generated per-language bindings ? From what I've seen so far they are mostly used as strings, so the limitations would be more on the processing/storage side.

After digging a bit further this kind of limitation comes from the generated code par, where in some cases it could create conflicts, for example foo.bar and foo_bar both being represented with FOO_BAR in some languages.

It seems that #1462 could provide a solution by allowing to provide an explicit code friendly name (which we can ensure does not conflicts), but I definitely lack expertise to know if it would help solve this current issue. @lmolkova do you think this would be covered by the current proposal ?

One problem is that renaming with a prefix is not allowed by policy, as a result I get the following error when trying to validate policy:

Violation: Attribute 'code.column' name is used as a namespace in the following attributes '["code.column.number"]'.
  - Category         : naming_collision
  - Type             : semconv_attribute
  - SemConv group    :
  - SemConv attribute: code.column
  - Provenance: /home/weaver/source

Violation: Attribute 'code.function' name is used as a namespace in the following attributes '["code.function.name"]'.
  - Category         : naming_collision
  - Type             : semconv_attribute
  - SemConv group    :
  - SemConv attribute: code.function
  - Provenance: /home/weaver/source

I don't know where does this restriction comes from, is it related to the generated per-language bindings ? From what I've seen so far they are mostly used as strings, so the limitations would be more on the processing/storage side.

We can add exceptions here: https://github.com/open-telemetry/semantic-conventions/blob/main/policies/attribute_name_collisions.rego#L83

This rule is in place to avoid conflicts if we ever "un-flatten" attributes. E.g. if an attribute of x can have an "AnyValue" with field y and this means the same as x.y.

We should ensure we never send the attribute as a namespace and the new attribute in the same signal.

@lmolkova will update policy to avoid this warning if the namespace attribute becomes deprecated.

Thanks to #1642 this is now unblocked and all the checks are now passing, it should now be ready for review.

Probably we should also rename code.filepath to code.file.path, for the reasons above and also to match file.path

Done in 9303339, I have also updated this PR description.

As a reminder, the current state of this PR renames the following fields, there has been some approvals before the code.filepath was also renamed, so it's probably safer to be explicit here:

• code.function renamed to code.function.name
• code.lineno renamed to code.line.number
• code.column renamed to code.column.number
• code.filepath renamed to code.file.path

There is only one unresolved conversation: #1624 (comment), which is mostly about introducing a breaking change, @trask @lmolkova what do you think are the best next steps ? Do you think it's worth doing a proper migration plan ?

@SylvainJuge let's follow @trask's proposal in #1624 (comment) to add a warning - this would reduce any additional churn (if any).

Instrumentations that emit existing code attributes may still provide migration plan if necessary, without us requiring everyone to do it.

@SylvainJuge let's follow @trask's proposal in #1624 (comment) to add a warning - this would reduce any additional churn (if any).

I've added a warning (and a dedicated README.md) in c108ab2, let me know if that's enough for now.