-The meta-data is located in a stream named "metadata". It is made of "event
-packets", which each start with an event packet header. The event type within
-the metadata stream have no event header nor event context. Each event only
-contains a null-terminated "string" payload, which is a metadata description
-entry. The events are packed one next to another. Each event packet start with
-an event packet header, which contains, amongst other fields, the magic number
-and trace UUID.
-
-The metadata can be parsed by reading through the metadata strings, skipping
-newlines and null-characters. Type names are made of a single identifier, and
-can be surrounded by prefix/postfix. Text contained within "/*" and "*/", as
-well as within "//" and end of line, are treated as comments. Boolean values can
-be represented as true, TRUE, or 1 for true, and false, FALSE, or 0 for false.
+The meta-data is located in a stream identified by its name: "metadata".
+It is made of "event packets", which each start with an event packet
+header. The event type within the metadata stream have no event header
+nor event context. Each event only contains a null-terminated "string"
+payload, which is a metadata description entry. The events are packed
+one next to another. Each event packet start with an event packet
+header, which contains, amongst other fields, the magic number and trace
+UUID. In the event packet header, the trace UUID is represented as an
+array of bytes. Within the string-based metadata description, the trace
+UUID is represented as a string of hexadecimal digits and dashes "-".
+
+The metadata can be parsed by reading through the metadata strings,
+skipping null-characters. Type names are made of a single identifier,
+and can be surrounded by prefix/postfix. Text contained within "/*" and
+"*/", as well as within "//" and end of line, are treated as comments.
+Boolean values can be represented as true, TRUE, or 1 for true, and
+false, FALSE, or 0 for false.
+
+
+7.1 Declaration vs Definition
+
+A declaration associates a layout to a type, without specifying where
+this type is located in the event structure hierarchy (see Section 6).
+This therefore includes typedef, typealias, as well as all type
+specifiers. In certain circumstances (typedef, structure field and
+variant field), a declaration is followed by a declarator, which specify
+the newly defined type name (for typedef), or the field name (for
+declarations located within structure and variants). Array and sequence,
+declared with square brackets ("[" "]"), are part of the declarator,
+similarly to C99. The enumeration type specifier and variant tag name
+(both specified with "<" ">") are part of the type specifier.
+
+A definition associates a type to a location in the event structure
+hierarchy (see Section 6). This association is denoted by ":=", as shown
+in Section 7.3.
+
+
+7.2 Metadata Scopes
+
+CTF metadata uses two different types of scoping: a lexical scope is
+used for declarations and type definitions, and a dynamic scope is used
+for variants references to tag fields.
+
+7.2.1 Lexical Scope
+
+Each of "trace", "stream", "event", "struct" and "variant" have their own
+nestable declaration scope, within which types can be declared using "typedef"
+and "typealias". A root declaration scope also contains all declarations
+located outside of any of the aforementioned declarations. An inner
+declaration scope can refer to type declared within its container
+lexical scope prior to the inner declaration scope. Redefinition of a
+typedef or typealias is not valid, although hiding an upper scope
+typedef or typealias is allowed within a sub-scope.
+
+7.2.2 Dynamic Scope
+
+A dynamic scope consists in the lexical scope augmented with the
+implicit event structure definition hierarchy presented at Section 6.
+The dynamic scope is only used for variant tag definitions. It is used
+at definition time to look up the location of the tag field associated
+with a variant.
+
+Therefore, variants in lower levels in the dynamic scope (e.g. event
+context) can refer to a tag field located in upper levels (e.g. in the
+event header) by specifying, in this case, the associated tag with
+<header.field_name>. This allows, for instance, the event context to
+define a variant referring to the "id" field of the event header as
+selector.
+
+The target dynamic scope must be specified explicitly when referring to
+a field outside of the local static scope. The dynamic scope prefixes
+are thus:
+
+ - Stream Packet Context: <stream.packet.context. >,
+ - Event Header: <stream.event.header. >,
+ - Stream Event Context: <stream.event.context. >,
+ - Event Context: <event.context. >,
+ - Event Payload: <event.fields. >.
+
+Multiple declarations of the same field name within a single scope is
+not valid. It is however valid to re-use the same field name in
+different scopes. There is no possible conflict, because the dynamic
+scope must be specified when a variant refers to a tag field located in
+a different dynamic scope.
+
+The information available in the dynamic scopes can be thought of as the
+current tracing context. At trace production, information about the
+current context is saved into the specified scope field levels. At trace
+consumption, for each event, the current trace context is therefore
+readable by accessing the upper dynamic scopes.
+
+
+7.3 Metadata Examples