clean up

CONTRIBUTING.md

@@ -107,26 +107,30 @@ The YAML (model definition) and Markdown (documentation) files are organized in
 │   ├── {domain}
 │   │   ├── {domain}-events.yaml
 │   │   ├── {domain}-metrics.yaml
-│   │   ├── {domain}-resources.yaml
+│   │   ├── {domain}-registry.yaml
 │   │   ├── {domain}-spans.yaml
-│   ├── registry
-│   │   ├── {domain}.yaml
+|   ├── resources
+│   │   ├── {domain}-resources.yaml
+│   │   ├── {domain}-registry.yaml
 ```
 
-All attributes must be defined in the domain-specific file under `/model/registry`.
+All attributes must be defined in the domain-specific folder under
+`/{domain}/{domain}-registry` or `/resource/{domain}-registry.yaml`.
+
 Corresponding markdown files are auto-generated (see [Update the markdown files](#2-update-the-markdown-files))
 in `/docs/attribute_registry` folder.
 
-Semantic conventions definitions for domain-specific signals should be placed under
+All semantic conventions definitions for domain-specific signals should be placed under
 `/model/{domain}` and should follow `{domain}-{signal}.yaml` pattern. For example,
 HTTP spans are defined in `model/http/http-spans.yaml`.
 
+Resources are considered to be their own domain and are defined in the `model/resources`
+folder.
+
 Domain-specific YAML definitions could be broken down into multiple files. For example,
 AWS spans are defined in `/model/aws/aws-lambda-spans.yaml`
 and `/model/aws/aws-sdk-spans.yaml` files.
 
-
-
 #### Schema files
 
 When making changes to existing semantic conventions (attributes, metrics, etc)

model/general/general.yaml

@@ -63,57 +63,4 @@ groups:
       - ref: code.column
       - ref: code.stacktrace
         requirement_level: opt_in
-  - id: url
-    brief: Attributes describing URL.
-    type: attribute_group
-    attributes:
-      - ref: url.scheme
-      - ref: url.full
-        tag: sensitive-information
-      - ref: url.path
-      - ref: url.query
-        tag: sensitive-information
-      - ref: url.fragment
-  - id: session-id
-    type: attribute_group
-    brief: >
-      Session is defined as the period of time encompassing all activities performed by the application and the actions
-      executed by the end user.
 
-      Consequently, a Session is represented as a collection of Logs, Events, and Spans emitted by the Client Application
-      throughout the Session's duration. Each Session is assigned a unique identifier, which is included as an attribute in
-      the Logs, Events, and Spans generated during the Session's lifecycle.
-
-      When a session reaches end of life, typically due to user inactivity or session timeout, a new session identifier
-      will be assigned. The previous session identifier may be provided by the instrumentation so that telemetry
-      backends can link the two sessions.
-    attributes:
-      - ref: session.id
-        requirement_level: opt_in
-      - ref: session.previous_id
-        requirement_level: opt_in
-  - id: network-core
-    type: attribute_group
-    brief: >
-      These attributes may be used for any network related operation.
-    attributes:
-      - ref: network.transport
-      - ref: network.type
-      - ref: network.protocol.name
-      - ref: network.protocol.version
-      - ref: network.peer.address
-      - ref: network.peer.port
-      - ref: network.local.address
-      - ref: network.local.port
-
-  - id: network-connection-and-carrier
-    type: attribute_group
-    brief: >
-      These attributes may be used for any network related operation.
-    attributes:
-      - ref: network.connection.type
-      - ref: network.connection.subtype
-      - ref: network.carrier.name
-      - ref: network.carrier.mcc
-      - ref: network.carrier.mnc
-      - ref: network.carrier.icc

model/general/network-common.yaml

@@ -0,0 +1,26 @@
+groups:
+  - id: network-core
+    type: attribute_group
+    brief: >
+      These attributes may be used for any network related operation.
+    attributes:
+      - ref: network.transport
+      - ref: network.type
+      - ref: network.protocol.name
+      - ref: network.protocol.version
+      - ref: network.peer.address
+      - ref: network.peer.port
+      - ref: network.local.address
+      - ref: network.local.port
+
+  - id: network-connection-and-carrier
+    type: attribute_group
+    brief: >
+      These attributes may be used for any network related operation.
+    attributes:
+      - ref: network.connection.type
+      - ref: network.connection.subtype
+      - ref: network.carrier.name
+      - ref: network.carrier.mcc
+      - ref: network.carrier.mnc
+      - ref: network.carrier.icc

model/general/url-common.yaml

@@ -0,0 +1,14 @@
+groups:
+  - id: url
+    brief: Attributes describing URL.
+    type: attribute_group
+    attributes:
+      - ref: url.scheme
+      - ref: url.full
+        tag: sensitive-information
+      - ref: url.path
+      - ref: url.query
+        tag: sensitive-information
+      - ref: url.fragment
+
+

model/session/session-common.yaml

@@ -0,0 +1,19 @@
+groups:
+  - id: session-id
+    type: attribute_group
+    brief: >
+      Session is defined as the period of time encompassing all activities performed by the application and the actions
+      executed by the end user.
+
+      Consequently, a Session is represented as a collection of Logs, Events, and Spans emitted by the Client Application
+      throughout the Session's duration. Each Session is assigned a unique identifier, which is included as an attribute in
+      the Logs, Events, and Spans generated during the Session's lifecycle.
+
+      When a session reaches end of life, typically due to user inactivity or session timeout, a new session identifier
+      will be assigned. The previous session identifier may be provided by the instrumentation so that telemetry
+      backends can link the two sessions.
+    attributes:
+      - ref: session.id
+        requirement_level: opt_in
+      - ref: session.previous_id
+        requirement_level: opt_in