Skip to content

YAML – Node Properties

In YAML, every piece of data (scalar, sequence, or mapping) is represented as a node in an underlying graph structure. Each node can have properties, primarily anchors and tags, which provide additional information or functionality. These properties can be explicitly specified or inferred by the YAML processor.

Anchors and aliases are a powerful YAML feature for data reuse, promoting the DRY (Don’t Repeat Yourself) principle. An anchor (&anchor_name) marks a node with a name, and an alias (*anchor_name) references that named node, effectively inserting its content at the alias’s position.

The YAML processor resolves aliases by replacing them with the content of the anchored node. The anchor name itself is not part of the data model after parsing, though some tools might preserve it for round-tripping.

# Example of an anchor and alias
default_settings: &common_config
timeout: 30
retries: 3
service_a_config:
<<: *common_config # Merge common_config (using an alias)
specific_setting: value_a
service_b_config:
<<: *common_config # Merge common_config again
timeout: 60 # Override timeout from common_config
specific_setting: value_b
# Parsed representation (conceptual)
# service_a_config:
# timeout: 30
# retries: 3
# specific_setting: value_a
# service_b_config:
# timeout: 60
# retries: 3
# specific_setting: value_b

In the example above, &amp;common_config anchors the default settings. *common_config is then used as an alias within a merge key (&lt;&lt;:) to include these settings in service_a_config and service_b_config.

Tags specify the data type of a node. YAML supports a rich tagging system, allowing for both standard types (like integers, strings, booleans) and custom, application-specific types. A tag is indicated by an exclamation mark (!).

There are different forms of tags:

  • Core/Schema Tags (!!tag_name): Double exclamation marks usually denote types defined by a standard YAML schema (e.g., !!str for string, !!int for integer, !!map for mapping, !!seq for sequence). Often, these are inferred, and explicit tagging is not needed.
  • Application-Specific/Local Tags (!local_tag): A single exclamation mark followed by a name denotes a user-defined or application-specific type. The interpretation of these tags depends on the application processing the YAML.
  • Global URI Tags (!<tag:uri...>): Tags can also be specified as URIs for global uniqueness, e.g., !<tag:yaml.org,2002:str>.
# Example of node tags
# Inferred types (Core Schema often handles these implicitly)
count: 123 # Likely !!int
name: Alice # Likely !!str
is_active: true # Likely !!bool
# Explicit tagging
explicit_string: !!str 42
explicit_integer: !!int "42"
# Custom application tag
my_object: !<myapp/user>
username: bob
email: bob@example.com
# Another custom tag form
coordinates: !point { x: 10, y: 20 }

Tags instruct the YAML parser on how to construct the native data object. For custom tags, the application needs to provide logic to handle them.

The content of a node is its actual data value. This can be a scalar (like a string or number), a sequence (list), or a mapping (dictionary/object). Node content can be represented in either block style (using indentation for structure) or flow style (inline, using [] for sequences and {} for mappings).

# Example of node content styles
# Block style mapping
block_map:
key1: value1
key2: value2
# Flow style mapping
flow_map: {key1: value1, key2: value2}
# Block style sequence
block_seq:
- item1
- item2
# Flow style sequence
flow_seq: [item1, item2]
# Scalar content
scalar_content: This is a string.

Understanding node properties (anchors, tags) and content styles (block, flow) is essential for effectively using YAML’s expressive power for data representation.