Yaml Ain't Markup Language (YAML) (tm) 1.0

The type family mechanism provides an abstraction of data types which is portable across various languages and platforms. Each native binding may have zero or more native concrete types or class constructs which correspond to a given type family.

name

A URI used as a globally unique identifier for the type family. YAML does not require that this URI point to anything in particular. However, where possible, it is considered good practice to have the URI point to some human-readable document providing information about the type data family.

definition

A description of the particular category of information, independent of language and platform.

formats

Each type family used for scalar nodes has associated string formats. These formats can be separated into two groups, implicit formats and explicit formats. In addition, one of the formats is designated to be the type family's canonical string format.

Type families used for collection nodes do not have any associated string formats.

implicit formats

A set of zero or more string formats used for implicit typing. Each format may only be used in a single type family for this purpose.

explicit formats

A set of zero or more string formats used for explicit typing. It is possible for two type families to share the same explicit format, though this practice is discouraged.

canonical format

In addition to the above, each scalar type family must provide a canonical string format. This must be one of the implicit or explicit formats, or a subset of one of these formats. The canonical format must provide exactly one unique string representation for each possible value of the scalar.

In general, there may be more than one native type which corresponds to a YAML type family. In the Python language, for example, the integer family may be bound to either the plain integer capable of holding 32 bits, or the long integer with unlimited size. In ambiguous situations like this, the loader should choose between the alternative based on the requirements of the native binding.

In other cases, a binding may not have an appropriate native construct for a given type family. This may be addressed with a generic YAML construct to act as a place-holder so that the data value and the type family may round-trip. Alternatively, with warning to the user, a value may be cast to a different, perhaps less specific family. Otherwise, when a native binding for a particular value is not possible, the parser must treat it as an error.

It may be possible to write a string value of a leaf in more than one way. For example, an integer value of 255 can also be written in hex as 0xFF. This distinction is covered by the concept of a string format.

name

Each string format has a name used for for explicit typing and for general identification. This name must comply with the format production, and must be unique within the type families it applies to.

definition

A description of the format as it applies to particular data values.

regexp

Regular expressions may be provided to allow implicit typing using the string format, or to enable the YAML processor to validate that a given value is indeed compliant with the string format.

As noted above, each scalar type family has exactly one canonical string format, although more than one string format may apply. For example, the scientific format is the canonical format for floating point numbers, but such numbers are typically written using the fixed format.

A graph node is the building block of YAML structures. In the serialization, they are represented by indented blocks. Within a native binding they represent application-specific objects. In the graph model, a node is tagged with a type family and can either be a collection or a scalar.

kind

A node may be one of two kinds, a collection or a scalar.

type family

Each node is associated with a type family. For native data, this association may be implicit, based on the native data type of the node.

In most programming languages, there are two manners in which variables can be equivalent. The first is by reference, where the two variables refer to the same memory address. We call this equivalence relation "identity".

The second form of equivalence occurs when two nodes are different (have a different memory addresses), but share the same content (same binary layout). We call this second form of equivalence "equality". It follows that when two nodes are identical they are also equal.

A node set is an unordered association of zero or more graph nodes. A node may participate in many node sets without restriction, allowing for a graph structure. Node sets may not contain duplicates, that is, a node with a particular identity may only appear once. The primary purpose of the node set is to provide a basis for the definition of a collection. A native binding usually exposes node sets through a mechanism to enumerate the keys of a hash or dictionary.

A collection is a graph node which represents sequences such as lists or arrays, or mappings such as hashes or dictionaries. In the graph model, sequences are treated uniformly as mappings with integer keys. There are three collection rules. First, a set of keys may not contain two nodes that are equal. Second, each key is associated with exactly one value. Finally, each value is associated with at least one key. Note that this does not prevent a value from being associated with more than one key.

domain

A domain is a node set restricted such that no two nodes in the set may be equal. Nodes which are members of the domain are often called "keys".

range

A range is node set without restrictions. Nodes which are members of the range are often called "values".

function

A function is a rule of correspondence from the domain onto the range such that there is a unique value in the range assigned to every key in the domain, and every value in the range is assigned to at least one key.

YAML requires the mapping collection type family, which covers associative containers such as the Perl hash or Python dictionary. When the domain is a series of sequential integers starting with zero, the preferred type family is the sequence which corresponds to a Perl array or a Python list.

Node equality determines when two given nodes have the same content. When two nodes are equivalent under this equivalence relation, they are said to be "equal". Equality is defined between scalar nodes and between collection nodes, as described below.

scalar equality

Two scalars are equal if and only if they have the same type family and their canonical string representations have exactly the same series of Unicode characters.

collection equality

Equality of a collection is defined recursively. Two collections are equal if and only if they have the same type family and for each key in the domain of one, there is a corresponding key in the domain of the other such that both keys are equal and their corresponding values are equal; here corresponding value refers to the unique node in the range of the collection assigned to the key by the collection's function.

A YAML text (file or stream) is a series of disjoint graphs, each with a root node.

stream

A series of zero or more document root nodes.

document

A top level graph node that is disjoint from all other root document nodes.

The term disjoint means that for any two nodes x and y, there does not exist a third node z that is reachable from both x and y. For any node x, x is reachable from y if and only if either x and y are identical, or y is a collection and there exists a node z in the domain or the range of y such that x is reachable from z.

To lay out graph nodes as a tree structure, a mechanism is needed to manage duplicate occurrences. This is solved with three node kinds: branch, leaf, and alias. The first occurrence of a scalar is represented by a leaf, the first occurrence of a collection is represented by a branch, and subsequent occurrences of either a collection or a scalar are represented by an alias. All tree nodes in this model have the following properties:

kind

A tree node may be one of three kinds, a branch, a leaf or an alias.

parent

The parent property gives access to the branch which holds the current tree node.

anchor

The anchor is a Unicode string which complies with the anchor production. The anchor is used to associate the first occurrence of a graph node with subsequent occurrences, via the alias tree node. This property is optional for leaf or branch nodes, provided that the scalar or collection represented does not occur more than once.

Note that when a tree node is converted to a graph node, the anchor, if any, is not converted. Likewise the parent property and the alias kind are not preserved as the graph node may participate in several collections.

Leaf tree nodes represent the first occurrence of a scalar in a given serialization.

type family

Like a scalar, each leaf is associated with a type family.

format

Unlike a scalar, each leaf is associated with a specific string format.

string value

Each leaf has a string value which is a string representation of the scalar according to the specific string format used.

When a leaf is converted into a graph node it becomes a scalar of the same type family. The scalar's value would be such that its string representation according to the specific format used would be identical to the leaf's string value. Note that the particular format used is not converted.

A pair is an ordered set of two tree nodes. The first member of the set is the key and the second member of the set is the value.

Branch tree nodes represent the first occurrence of a collection in a given serialization.

type family

Like a collection, each branch is associated with a type family.

pairs

A branch has an ordered set of zero or more pairs.

When a branch is converted into a graph node, three operations occur. The domain is constructed with the graph node for each key in its set of pairs. Likewise, the range is constructed with the graph node for each value in its set of pairs. Last, the function is constructed via assocation of key graph nodes to value graph nodes, as provided by the set of pairs. Note that the ordering of the pairs is explicitly not converted.

When serializing a YAML graph, every tree node is put into a single linear sequence within a given document through the branch pair ordering. With the composition of branches, this ordering becomes total, so that for any two distinct tree nodes in a serialization, one can be said to precede another.

For any two nodes or aliases, x and y we say that x precedes y when any of the following holds:

• x is the parent of y.

• x is a key and y is a value in a given pair.

• x and y are nodes in two pairs within a branch, and the pair containing x comes before the pair containing y.

• There exists a node z such that x precedes z and z precedes y.

The tree node is extended with a style property, which can have different values depending upon its kind.

leaf style

Leaf styles include eight nested styles and three in-line styles. All but the escaped and double quoted styles are limited to scalars having only printable characters.

branch style

Branch styles are series and keyed. The series style may only be used if the domain of the collection's function is the set of sequential positive integers starting at zero.

The syntax model allows optional comment blocks to be interleaved with the node blocks. Comment blocks may appear before or after any node block. A comment block can't appear in a nested leaf node block value.

comment

A comment is a series of zero or more Unicode characters complying with the comment productions.

Serialized YAML uses a subset of the Unicode character set. A YAML parser must accept all printable ASCII characters, the space, tab, line break, and all Unicode characters beyond 0x9F. A YAML emitter must only produce those characters accepted by the parser, but should also escape all non-printable Unicode characters if a character table is readily available.

The range above explicitly excludes the surrogate block [#xD800-#xDFFF], DEL 0x7F, the C0 control block [#x0-#x1F], the C1 control block [#x80-#x9F], #xFFFE and #xFFFF. Note that in UTF-16, characters above #xFFFF are represented with a surrogate pair. DEL and characters in the C0 and C1 control block may be represented in a YAML serilization using escape sequences.

A YAML processor is required to support the UTF-32, UTF-16 and UTF-8 character encodings. If an input stream does not begin with a byte order mark, the encoding shall be UTF-8. Otherwise the encoding shall be UTF-32 (LE or BE), UTF-16 (LE or BE) or UTF-8, as signaled by the byte order mark. Note that as YAML files may only contain printable characters, this does not raise any ambiguities. For more information about the byte order mark and the Unicode character encoding schemes see the Unicode FAQ.

Indicators are special characters which are used to describe the structure of a YAML document.

Indicators can be grouped into three categories. The '-' and ':' space indicators are always followed by a white space character (space, tab or line break). If followed by any other character, these indicators are treated as content. The '[', ']', '{', '}' and ',' in line indicators are used to denote in-line branch structure and therefore must not be used as content text characters unless protected in some way. The remaining indicators are used to denote the start of various YAML elements and hence may used as internal content text character in most cases. The exact restrictions on the use of indicators as content text characters depend on the particular leaf style used.

The Unicode standard defines the following line break characters.

Line breaks can be grouped into two groups. Specific line breaks have well-defined sematics for breaking text into lines and paragraphs. The semantics of generic line break characters is not defined beyond ending a line.

Outside text content, YAML allows any line break to be used to terminate lines, and in most cases also allows such line breaks to be preceded by trailing line space characters. On output, a YAML emitter is free to emit non content line breaks using whatever convention is most appropriate. An emitter should avoid emitting trailing line spaces.

This section includes several common character range definitions.

In a YAML serialization, structure is determined from indentation, where indentation is defined as a line break character followed by zero or more space characters.

Tab characters are not allowed in indentation unless a '#TAB' directive is used. If such a directive is used, each indentation tab is equivalent to a certain number of spaces determined by the specified tab policy.

A node must be more indented than its parent node. All sibling nodes must use the exact same indentation level. However the content of each such node may be indented independently.

The indentation level is used exclusively to delineate structure. Indentation characters are otherwise ignored. In particular, they are never taken to be a part of the value of serialized text.

Since the YAML serialization depends upon indentation level to delineate blocks, additional productions are a function of an integer, based on the indent(n), indent(<n) and indent(<=n) productions above.

Throwaway comments have no effect whatsoever on the tree or graph models represented in the file. Their usual purpose is to communicate between the human maintainers of the file. A typical example is comments in a configuration file.

A throwaway comment always spans a complete line. An explicit throwaway comment line consists of of some indentation, a '#' indicator, and arbitrary comment characters to the end of the line. Empty lines or lines containing only indentation spaces are taken to be an implicit throwaway comment.

A throwaway comment may appear before a document node or following any node. A throwaway comment may not appear inside a nested line leaf node, but may precede or follow such a node. When following a nested leaf value, the first comment line must be explicit and be less indented than the nested node value. Following comment lines are not restricted.

# These are three throwaway comment

# lines (the second line is empty).
this: |
    contains two lines of text, the
    # second of which starts with '#'.
# A comment may follow a leaf value.

A YAML stream may contain several independent YAML documents. A document header line is used to separate documents. This line must start with a document separator - '--' followed by a series of non-space characters. The same separator line must be used in all the document headers throughout the stream.

If no explicit header line is specified at the start of the stream, the parser should behave as if a header line containing '--- #YAML:1.0 #TAB:NONE' was specified.

--- ]
This YAML stream contains a single text value.
The next stream is a log file - a series of log
entries. Adding an entry to the log is a simple
matter of appending it at the end.

---
at: 2001-08-12 09:25:00.00
type: GET
HTTP: '1.0'
url: '/index.html'
---
at: 2001-08-12 09:25:10.00
type: GET
HTTP: '1.0'
url: '/toc.html'

# This stream is an example of a top level map.
invoice : 34843
date    : 2001-01-23
total   : 4443.52

# The following is a sequence of five documents.
# The first two contain an empty map, the second two
# an empty sequence, and the last an empty string.
--- {}
--- !map
--- []
--- !seq
---

Directives are instructions to the YAML parser. Like throwaway comments, directives are not reflected in the tree or graph models. Directives apply to a single document. It is an error for the same directive to be specified more than once for the same document.

YAML defines two directives, '#YAML' and '#TAB'. Additional directives may be added in future versions of YAML. A parser should ignore unknown directives with an appropriate warning. There is no provision for specifying private directives. This is intentional.

#YAML

The '#YAML' directive specifies the version of YAML the document adheres to. This specification defines version '1.0'.

A version 1.0 parser should accept documents with an explicit '#YAML:1.0' directive, as well as documents lacking a '#YAML' directive. Documents with a directive specifying a higher minor version (e.g. '#YAML:1.1') should be processed with an appropriate warning. Documents with a directive specifying a higher major version (e.g. '#YAML:2.0') should be rejected with an appropriate error message.

#TAB

Since different systems treat tabs differently, portability problems are a concern. Therefore, the default tab policy of YAML is conservative ('#TAB:NONE'); don't allow them in indentation. However, for some users, their editor may make it difficult to not use tabs. In this case, the '#TAB' directive is available so that the tab policy is explicitly provided to the YAML parser. Note that tab characters in text content are always valid and must be preserved by the parser, regardless of the tab policy used.

YAML supports the following tab policies:

#TAB:NONE

This default policy forbids the use of tabs in indentation. If such a tab character is detected, the parser must treat it as an error. The error message should refer to the need for providing an explicit tab policy for tabs to be used as indentation characters.

Many editors can be configured such that pressing the tab key is automatically converted to the insertion of a appropriate number of spaces into the edited file, and in general support convenient editing of indented blocks without making use of tab characters. Where possible, YAML editors should be configured to using this indentation policy, as it is the only truly portable one. The https://yaml.org/editors page contains instructions on configuring known editors to use this policy.

#TAB:N (for some positive integer N)

Tab characters in indentation are equivalent to the number of spaces which would bring the indentation level to the next multiple of N.

Almost every editor supports this type of policy, with '#TAB:8' being the most common, followed by '#TAB:4'. Most editors also allow users to configure the value of N. Typically an editor providing this flexibility can also be configured to use the '#TAB:NONE' policy as described above.

#TAB:N:HARD (for some positive integer N)

Tab characters in indentation are equivalent to exactly N spaces. This type of policy has much less support by editors. However, if an editor does use this type of policy, it is less likely to allow configuration to using a different type.

When either a '#TAB:N' or a '#TAB:N:HARD' policy is used, the parser must expand indentation tabs to spaces accordingly. Each tab, when expanded to spaces, must not span beyond the indentation into the serialized text. While this is an error, parsers should recover from it with a warning, by assigning some of the spaces to the indentation and some to the serialized text.

A serialization node begins at a particular level of indentation, n, and its content is indented at some level >n. A serialization node can be either a branch (keyed or series), a leaf (nested or in-line) or an alias.

A YAML document is a normal node. However a document can't be an alias (there is nothing it may refer to). Also if the header line is omitted the first document must be a nested (not in-line) branch.

Each serialization node may have anchor and transfer method properties. These properties are specified in a properties list appearing before the node value itself. For a top level node (a document), the properties appear in the document header line, following the directives (if any). It is an error for the same property to be specified more than once for the same node.

The transfer method property specifies how to deserialize the associated node. It includes the type family for the node and optionally the specific format used, separated by a '|' character.

A type family may be either public or private. A public type family name is a globally unique URI. A private type family names must begin with a '!' character. Such type families should not be expected to have consistent semantics in different documents.

By providing an explicit transfer property to a node, implicit typing is prevented. However, an explicit empty transfer method property can be used to force implicit typing to be applied to a non-simple leaf value.

Escaping

URIs support a limited ASCII-based character set. Hence, when parsing a URI type family name, the parser must convert any non-ASCII character to UTF-8 encoding, then use '%' style escaping to represent the resulting bytes.

In general, expanding '%' escaped characters may change the semantics of a URI. Hence the parser must accepts such sequences and pass them unmodified to the application.

The parser must also accept YAML style escape sequences. These must be converted to '%' style escape sequences as described above even if the specified character is a valid printable ASCII URI character. Thus the parser must convert the YAML escape sequence '\x30' to the URI escape sequence '%30' rather than to the digit '0'.

Prefixing

YAML provides convenient shorthand for the common case where a node and (most of) its decsendents have public types families whose URIs share a common prefix.

For this case, YAML allows using the '^' character to separate the ancestor node's type family URI into a prefix and a suffix. The parser does not consider the separator to be part of type family name.

When the parser encounters a descendant node whose type family name begins with '^', it appends the ancestor node's prefix to it. Again the '^' character is not taken to be part of the name.

It is possible for a descendant node to establish a different prefix. In this case the node may not make use of its ancestor's node prefix. It must specify a full type family name URI, separated into a prefix and suffix as above.

It is an error for a node's type family name to begin with '^' unless it has an ancestor node establishing a prefix. However, a node may establish a prefix even if none of its decendents make use of it.

Note that the type prefix mechanism is purely syntactical and does not imply any additional semantics. In particular, the prefix must not be assumed to be an identifier for anything.

Shorthands

To increase readability, YAML provides shorthand notations for certain type family URIs. Like the prefixing mechanism, shorthand notations are merely syntactical and do not imply any additional semantics. Note that it is valid to use a shorthand type family in order to establish a prefix.

• If the type family contains no ':' and no '/' characters it is prefixed with https://yaml.org/. Thus the parser must report a node with the type family !seq as if it was written using the full !https://yaml.org/seq notation.

• Otherwise, if the type family begins with a single word followed by a '/' character, it is assumed to belong to a sub-domain of yaml.org. Hence the parser must report a node with the type family !perl/Text::Tabs as if it was written using the full !http://perl.yaml.org/Text::Tabs notation.

  Each domain language.yaml.org will include all globally unique types of the language which aren't covered by the set of language-independent types. Globally unique types for each language include any built-in types and any standard library types. For languages such as Java and C#, all type names based on reverse DNS strings are globally unique. For languages such as Perl, which has a central authority (CPAN) for managing the global namespace, all the types sanctioned by the central authority are globally unique. The list of supported languages and their types is maintained as part of the YAML type repository.

• Otherwise, if the type family contains a '/' before any ':' characters it may include, it is prefixed with http://. Therefore the parser must report a node with the type family !clarkevans.com/timesheet as if it was written using the full !http://clarkevans.com/timesheet notation.

• Otherwise, the type family contains a ':' before any '/' characters it may include, is assumed to begin with an explicit URI scheme, and is preserved. Hence the parser must report a node with the type family !modem:+3585551234567;type=v32b?7e1;type=v110 as it is written.

# All entries in the series
# have the same type and value.
- 10.0
- !float 10
- !yaml.org/^float '10'
- !https://yaml.org/float ]\
  1\
  0

# Private types are per-document.
---
pool: !!ball
   number: 8
   color: black
---
bearing: !!ball
        material: steel

# 'http://company.tld/invoice' is some type family.
invoice: !company.tld/^invoice
  # 'seq' is a shorthand for 'https://yaml.org/seq'.
  # This does not effect '^customer' below
  # because it is does not specify a prefix.
  customers: !seq
    # '^customer' is a shorthand for the full
    # notation 'http://company.tld/customer'.
    - !^customer
      given : Chris
      family : Dumars

# It is possible to use XML namespace URIs as
# YAML namespaces. Using the ancestor's URI
# allows specifying it only once. The $ separates
# between the XML namespace URI and the tag name.
doc: !http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd$^html
 - !^body
  - !^p This is an HTML paragraph.

An anchor is a property which can be used to mark a serialization node for future reference. An alias node can then be used to indicate additional inclusions of an anchored node by specifying the node's anchor.

A series node is the simplest node style. it contains a series of sub-nodes at a higher indentation level. An in-line style is available for short, simple series.

empty: []
inline: [ one, two, three ]
nested:
 - First item in top series
 -
  - Subordinate series entry
 - ]
  A multi-line
  series entry
 - Sixth item in top series

A keyed node is an association of unique keys with values. It is an error for two equal key entries to appear in the same keyed node. In such a case the parser may continue processing, ignoring the second key and issuing an appropriate warning. This strategy preserves a consistent information model for streaming and random access applications.

An in-line form is available for short, simple keyed nodes. Also, if a keyed node has no properties, it may start in-line in a series entry.

empty: {}
inline: { one: 1, two: 2 }
nested:
 first : First entry
 second:
  key: Subordinate keyed
 third:
  - Subordinate series
  - !map
  - Previous keyed is empty.
  - A key: value pair in a series.
    A second: key:value pair.
  - The previous entry is equal to the following one.
  -
   A key: value pair in a series.
   A second: key:value pair.
 !float 12 : This key is a float.
 ? ]
  ?
 : This key had to be protected.
 ? ]\
  \a
 : This key had to be escaped.
 "\b": Another way to escape
 ? ]
  This is a
  multi-line
  plain key
 : ]
  Whose value is
  also multi-line.
 ?
  - This key
  - is a series
 :
  - With a series value.
 ?
  This: key
  is a: mapping
 :
  with a: mapping value.

The style variant of a nested leaf node is defined using the following three independent properties: folding, escaping, and chomping. In addition, a nested leaf may have explicit indentation.

A nested leaf node may be in one of eight style variants defined by the three nested leaf properties.

empty: |
detected: |
 The \ character may be freely
 used. Leading white space
    is significant.

 All line breaks are significant,
 including the final one. Thus
 this value contains one empty
 line and ends with a line break,
 but does not start with one.
# Comments may follow a nested
 # leaf value. Once the first
  # comment line is seen, they
   # can be at any indentation
    # level, or even empty lines.

# Explicit indentation must
# be given in all the three
# following cases.
leading spaces: |2
      This value starts with
  four spaces. It ends with
  two line breaks.

leading line break: |2

  This value starts with
  a line break and ends
  with one.
leading comment indicator: |2
  # first line starts with a
  #. This value does not start
  with a line break but ends
  with one.
# Explicit indentation may
# also be given when it is
# not required.
redundant: |2
  This value is indented 2 spaces.

empty: |-
detected: |-
 All line breaks are significant,
 except for the trailing ones.
 Thus this value does not end
 with a line break.

# Comments may follow.

empty: |\
detected: |\
 Escape sequences may be used,
 for example this\nforces a
 line break and th\
 is isn't one. Quotes " '
 and other indicators may be
 freely used, but the \\
 character must be escaped.
explicit: |\2

  This value starts with
  a line break but does
  not end with one.\
# Comments may follow.

empty: |\-
detected: |\-
 Trailing line breaks
 are stripped, so this
 value does not end
 with a line break.

escaped: |\-
 Escaped line breaks
 are not chomped so
 this value ends with
 a single line break.\n

ignored: |\-
 It is possible to
 explicitly ignore
 a trailing line break,
 for example in case
 it is an LS or PS
 character.\
# Comments may follow.

empty: ]
detected: ]
 Line feeds are converted
 to spaces, and the final
 line break series is
 clipped, so this value
 contains no line breaks.
explicit: ]2

  An empty line, either
  at the start, end of
  in the value:

  Is interpreted as a
  line break. Thus this
  value contains three
  line breaks.

# Comments may follow.

empty: ]-
detected: ]-
 The final sequence of
 line breaks is chomped,
 so this value contains
 no line breaks.

# Comments may follow.

empty: ]\
detected: ]\
 Escaped line feeds are not
 converted to a space, so
 this \n is a line feed.
explicit: ]\2

  This value starts with
  a line feed, but doesn't
  end witj one even though
  it has a trailing empty
  line.\

# Comments may follow.

empty: ]\-
detected: ]\-
 Trailing line feeds are
 chomped, but escaped ones
 are preserved, so this
 value ends with a single
 line feed.\n

# Comments may follow.

An in-line leaf may be in one of three style variants. The double quoted style variant supports escaping and can be used to represent arbitrary Unicode strings. The single quoted style variant is limited to printable Unicode characters. The simple style variant is further restricted to not contain most indicator characters or leading or trailing space characters.

empty: ''
second: '! : \ etc. can be used freely.'
third: 'a single quote '' must be escaped.'

empty: ""
second: "! : etc. can be used freely."
third: "a \" or a \\ must be escaped."
fourth: "this value ends with an LF.\n"

empty:
second: The value of the previous key is the empty string.
third: 12
fourth: The above entry is an integer.