Copyright © 2001 Oren Ben-Kiki, Clark Evans & Brian Ingerson, all rights reserved. This document may be freely copied provided that it is not modified.
This specification is a working draft and reflects consensus reached
by the members of the yaml-core mailing list. Any questions regarding
this draft should be raised on this list at
With this release of the YAML specificiation, we now encourage development of YAML processors, so that the design of YAML can be validated and for early adoption. The specification is still subject to change; however, such changes will be limited to polish and fixing any logical flaws and bugs. Changes to the special keys area may also occur pending work on complementary specifications, but special keys are a rather isolated aspect of the specification.
Therefore, this is "Last Call" for changes; if you have a pet feature now is the very last time that they can be proposed before Release Canidate status. Changes which would cause "Last Call" YAML texts to be invalid will be seriously considered only if absolutely necessary.
YAML(tm) (rhymes with "camel") is a straightforward machine parsable data serialization format designed for human readability and interaction with scripting languages such as Perl and Python. YAML is optimized for data serialization, formatted dumping, configuration files, log files, Internet messaging and filtering. This specification describes the YAML information model and serialization format. Together with the Unicode standard for characters, it provides all the information necessary to understand YAML Version 1.0 and construct programs to process it.
YAML Ain't Markup Language, abbreviated YAML, is a human-readable data serialization format and processing model. This text describes the class of data objects called YAML document streams and partially describes the behavior of computer programs that process them.
YAML document streams encode into a serialized form the native data constructs of modern scripting languages. Strings, arrays, hashes, and other user-defined data types are supported. A YAML document stream consists of a sequence of characters, some of which are considered part of the document's content, and others that are used to indicate structure within the information stream.
A YAML processor is a software module that is used to manipulate YAML information. A processor may perform multiple functions, such as parsing a YAML serialization into a sequence of events, loading these events into a native language representation, dumping a native representation into a sequence of events, and emitting these events into a serialized form. It is assumed that a YAML processor does its work on behalf of another module, called an application. This specification describes the required behavior of a YAML processor. It describes how a YAML processor must read or write YAML document streams and the information structures it must provide to or obtain from the application.
The design goals for YAML are:
YAML documents are very readable by humans.
YAML interacts well with scripting languages.
YAML uses host languages' native data structures.
YAML has a consistent information model.
YAML enables stream-based processing.
YAML is expressive and extensible.
YAML is easy to implement.
YAML was designed with experience gained from the construction and deployment of Brian Ingerson's Perl module Data::Denter. YAML's initial direction was set by the markup language discussions among SML-DEV members. Since then YAML has matured through the support and encouragement it has received from its user community.
YAML integrates and builds upon structures and concepts described by C, Java, Perl, Python, RFC0822 (MAIL), RFC1866 (HTML), RFC2045 (MIME), RFC2396 (URI), SAX, SOAP and XML.
YAML's core type system is based on the serialization requirements of Perl. YAML directly supports both scalar values (string, integer) and collections (array, hash). Support for common types enables programmers to use their language's native data constructs for YAML manipulation, instead of requiring a special document object model (DOM).
Like XML's SOAP, the YAML serialization supports native graph structures through a rich alias mechanism. Also like SOAP, YAML provides for application-defined types. This allows YAML to serialize rich data structures required for modern distributed computing. YAML provides unique global type names using a namespace mechanism inspired by Java's DNS based package naming convention and XML's URI based namespaces.
YAML's block scoping is similar to Python's. In YAML, the extent of a node is indicated by its column. YAML's literal scalar leverages this by enabling formatted text to be cleanly mixed within an indented structure without troublesome escaping. Further, YAML's block indenting provides for easy inspection of the document's structure.
Motivated by HTML's end-of-line normalization, YAML's folded scalar introduces a unique method of handling white space. In YAML, single line breaks may be folded into a single space, while empty lines represent line break characters. This technique allows for paragraphs to be word-wrapped without affecting the canonical form of the content.
YAML's double quoted scalar uses
familar C-style escape sequences. This
enables ASCII representation of non-printable or 8-bit (ISO 8859-1)
characters such as '\x3B'.
16-bit Unicode and 32-bit (ISO/IEC 10646) characters are supported
with escape sequences such as '\u003B' and '\U0000003B'.
The syntax of YAML was motivated by Internet Mail (RFC0822) and remains partially compatible with this standard. Further, YAML borrows the idea of having multiple documents from MIME (RFC2045). YAML's top-level production is a stream of independent documents; ideal for message-based distributed processing systems.
YAML was designed to have an incremental interface that includes both a pull-style input stream and a push-style (SAX-like) output stream interfaces. Together this enables YAML to support the processing of large documents, such as a transaction log, or continuous streams, such as a feed from a production machine.
There are many differences between YAML and the eXtensible Markup Language (XML). XML was designed to be backwards compatible with Standard Generalized Markup Language (SGML) and thus had many design constraints placed on it that YAML does not share. Also XML, inheriting SGML's legacy, is designed to support structured documents, where YAML is more closely targeted at messaging and native data structures. Where XML is a pioneer in many domains, YAML is the result of many lessons from the XML community.
The YAML and XML information models are starkly different. In XML, the primary construct is an attributed tree, where each element has an ordered, named list of children and an unordered mapping of names to strings. In YAML, the primary graph constructs are sequence (natively stored as an array), mapping (natively stored as a hash) and scalar values (string, integer, floating point). This difference is critical since YAML's model is directly supported by native data structures in most modern programming languages, where XML's model requires mapping conventions, or an alternative programming component (e.g. a document object model).
The terminology used to describe YAML is defined in the body of this specification. The terms defined in the following list are used in building those definitions and in describing the actions of a YAML processor:
| may | Conformant YAML streams and processors are permitted to but need not behave as described. | |
| should | Conformant YAML texts and processors are encouraged to behave as described, but may do otherwise if a warning message is provided to the user and any deviant behavior requires conscious effort to enable. (i.e. a non-default setting) | |
| must | Conformant YAML texts and processors are required to behave as described, otherwise they are in error. | |
| error | A violation of the rules of this specification; results are undefined. Conforming software must detect and report an error and may recover from it. |
This section provides a quick glimpse into the expressive power of YAML. It is not expected that the first-time reader grok all of the examples. Rather, these selections are used as motivation for the remainder of the specification.
--- name: Mark McGwire hr: 65 avg: 0.278 --- name: Sammy Sosa hr: 63 avg: 0.288
|
# Ranking of players by # 1998 season home runs. --- - Mark McGwire - Sammy Sosa - Ken Griffey
|
||||
hr: # 1998 hr ranking - Mark McGwire - Sammy Sosa rbi: # 1998 rbi ranking - Sammy Sosa - Ken Griffey
|
hr: - Mark McGwire # Following node labeled SS - &SS Sammy Sosa rbi: - *SS # Subsequent occurance - Ken Griffey
|
||||
The question mark indicates a complex key. Within a block sequence, mapping pairs can start immediately following the dash. |
|||||
? # PLAY SCHEDULE
- Detroit Tigers
- Chicago Cubs
:
- 2001-07-23
? [ New York Yankees,
Atlanta Braves ]
: [ 2001-07-02, 2001-08-12,
2001-08-14 ]
|
invoice: 34843
date : 2001-01-23
bill-to: Chris Dumars
product:
- item : Super Hoop
quantity: 1
- item : Basketball
quantity: 4
- item : Big Shoes
quantity: 1
|
||||
Scalar values can be written in block form using a literal style (|) where all new lines count. Or they can be written with the folded style (>) for content that can be word wrapped. In the folded style, newlines are treated as a space unless they are part of a blank or indented line.
--- |
\/|\/|
/ | |_
|
--- >
Mark McGwire's
year was crippled
by a knee injury.
|
||||
--- >
Sammy Sosa completed another
fine season with great stats.
63 Home Runs
0.288 Batting Average
What a year!
|
name: Mark McGwire accomplishment: > Mark set a major league home run record in 1998. stats: | 65 Home Runs 0.278 Batting Average
|
||||
YAML's flow scalars include the plain style (most examples thus far) and quoted styles. The double quoted style provides escape sequences. Single quoted style is useful when escaping is not needed. All flow scalars can span multiple lines; intermediate whitespace trimmed to a single space. |
|||||
unicode: "Sosa did fine.\u263A" control: "\b1998\t1999\t2000\n" hexesc: "\x13\x10 is \r\n" single: '"Howdy!" he cried.' quoted: ' # not a ''comment''.' tie-fighter: '|\-*-/|'
|
plain: This unquoted
scalar spans
many lines.
quoted: "\
So does this quoted
scalar.\n"
|
||||
In YAML, plain (unquoted) scalars are given an implicit type depending on a regular expression matched. YAML's recognizes integers, floating point values, timestamps, null, boolean, and string values.
canonical: 12345 decimal: +12,345 octal: 014 hexadecimal: 0xC
|
canonical: 1.23015e+3 exponential: 12.3015e+02 fixed: 1,230.15 negative infinity: (-inf) not a number: (NaN)
|
||||
null: ~ true: + false: - string: '12345'
|
canonical: 2001-12-15T02:59:43.1Z iso8601: 2001-12-14t21:59:43.10-05:00 spaced: 2001-12-14 21:59:43.10 -05:00 date: 2002-12-14 # Time is noon UTC
|
||||
Explicit typing is denoted with the bang (!) symbol. Application types should include a domain name and may use the caret (^) to avoid typing. |
|||||
--- not-date: !str 2002-04-28 picture: !binary|base64 | R0lGODlhDAAMAIQAAP//9/X 17unp5WZmZgAAAOfn515eXv Pz7Y6OjuDg4J+fn5OTk6enp 56enmleECcgggoBADs= hmm: !somewhere.com,2002/type | family above is short for taguri:somewhere.com,2002:type
|
--- !clarkevans.com,2002/graph/^shape
- !^circle
center: &ORIGIN {x: 73, y: 129}
radius: 7
- !^line # !clarkevans.com,2002/graph/line
start: *ORIGIN
finish: { x: 89, y: 102 }
- !^text
start: *ORIGIN
color: 0xFFEEBB
value: Pretty vector drawing.
|
||||
Below are two full-length examples of YAML. On the left is a sample invoice; on the right is a sample log file.
--- !clarkevans.com,2002/^invoice
invoice: 34843
date : 2001-01-23
bill-to: &id001
given : Chris
family : Dumars
address:
lines: |
458 Walkman Dr.
Suite #292
city : Royal Oak
state : MI
postal : 48046
ship-to: *id001
product:
- sku : BL394D
quantity : 4
description : Basketball
price : 450.00
- sku : BL4438H
quantity : 1
description : Super Hoop
price : 2392.00
tax : 251.42
total: 4443.52
comments: >
Late afternoon is best.
Backup contact is Nancy
Billsmer @ 338-4338.
|
---
Time: 2001-11-23 15:01:42 -05:00
User: ed
Warning: >
This is an error message
for the log file
---
Time: 2001-11-23 15:02:31 -05:00
User: ed
Warning: >
A slightly different error
message.
---
Date: 2001-11-23 15:03:17 -05:00
User: ed
Fatal: >
Unknown variable "bar"
Stack:
- file: TopClass.py
line: 23
code: |
x = MoreObject("345\n")
- file: MoreClass.py
line: 58
code: |-
foo = bar
|
Each YAML file/stream is a series of disjoint directed graphs, each having a single root. YAML processing may be understood in terms of four interacting representations of the data: a serialization format, an event stream, a native binding and a generic view of this binding.
Translating YAML information between these representations are five processing components: a parser, a loader, a viewer, a dumper and an emitter. The parser extracts structured information from the input stream. The loader converts this information into an appropriate native structure. A viewer presents this native structure in a YAML-compatible way. A dumper converts this view into an event stream. An emitter converts this stream into YAML syntax.
| SYNTAX |
-
Parser -> |
SERIAL |
-
Loader -> |
|
----\ |
|||
<-
Emitter - |
<-
Dumper - |
For each one of the representations above, there is a corresponding information model. The native model is defined by the programming language used. The generic model provides a concrete uniform view of the native model. The serial model covers the one-pass view of this data. The syntax model covers the serialization format. Type information is moved between these representations using the type family and format constructs.
A processor need not expose the event stream (serial model) or uniform view (generic model) and may translate directly between a serialization and its native binding. However, such a direct translation should take place so that the native binding is constructed only from information available in the native model. In particular, information specific to the generic model (format), serial model (alias anchors and pair ordering) and syntax model (comments and styles) should not be used in the construction of a native binding. Exceptions to this guideline include editors that must operate on a direct image of the serialization format.
The native model may be implemented by arbitrary native data structures of the programming language used. The only constraint on the native representation is that it preserve the information defined by the native model.
Implementations of the generic model are, by necessity, specific to a particular programming language. Such implementations are constrained to only provide the information specified by the generic model.
The serial model is often implemented as an event stream, and is important for implementing one-pass operations on YAML data. Again, of necessity implementations are specific to a particular programming language, and are constrained to provide the information required by the serial model.
Serialization is fully defined by this specification and hence any instance is independent of the particular programming language chosen. This allows the definition of generic YAML tools that may be applied independently of the programming language used, as well as provides a way to interchange data between applications implemented in differing languages.
The native model abstracts data structures of common programming languages. In the native model, any data is viewed as a directed graph of typed nodes. Nodes that are defined in terms of other nodes are collections and nodes that are defined independent of any other nodes are scalars.
YAML supports two kinds of collection nodes, mappings and sequences. The native model also defines when two different nodes have the same content and provides a definition of node identity.
A native node is the building block of data structures. A native node stands for anything from a single integer to a complex data structure such as a complete VRML scene or SQL database. A native node has the following properties:
type familyvalueThe type family mechanism provides an abstraction of data types that is portable across languages and platforms. Each native binding may have zero or more native concrete types or class constructs that correspond to a given type family.
YAML supports both global and private type families. Global type families have consistent semantics across all YAML documents. Private type families should not be expected to maintain the same semantics in different documents, even if these appear in the same document stream.
nametaguri: scheme. Private type family names are URIs
under the x-private: scheme. See section 4.3.5 for further details. The
taguri: scheme is described in http://www.taguri.org.YAML only makes use of taguri: URIs that take
the form taguri:domain,date:identifier.
Specifically, it does not make use of taguri: URIs
that are based on an E-mail address. Nor does it make use of
URIs outside the taguri: scheme.
definitionim/mutableTo better understand this distinction, consider the following example:
C syntax: |
struct Point { int x; int y; } p = { 1, 2 };
YAML syntax: !Point { x: 1, y: 2 }
It is impossible to modify the integer value 1. The only
modification possible is constructing a new, unrelated integer
value 3 and using this new value for the X coordinate.
Performing this replacement would cause the point to change "in
place" from { x: 1, y: 2 }{ x: 3, y: 2 }
Typically collection type families are mutable and scalar type families are immutable, though exceptions are possible.
kindPoint
structures are mappings). In other cases, deciding on the kind
requires a data modeling decision (for example, whether a date
is thought of as a single scalar or as a mapping with
independent sub-parts).scalarsequencemappingdomainrangefunctioncollectionIn most programming languages, there are two distinct manners in which variables can be equivalent.
identityequalityEquality is defined between scalar nodes and between collection nodes, as described below.
scalar
equalitycollection
equalityFor immutable type families, the distinction between equal and identical nodes is only of interest for efficiency reasons (reducing memory usage), and has no semantic significance. Hence for such type families a YAML processor may freely replace two equal but separate (non-identical) nodes with two occurrences of the same (identical) node, and vice versa.
For mutable type families, however, this distinction is an important part of the information model and a YAML processor is required to preserve node identity. It follows that if a YAML processor supports the handling of unknown type families, it must treat them as mutable (preserve node identity). In particular, a YAML processor can not assume unknown scalar type families are immutable.
A YAML stream is a sequence of disjoint graphs, each with a root node.
streamdocumentThe 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.
The generic model provides a concrete uniform realization of the native model. This model allows the creation of generic YAML APIs and tools that can apply to arbitrary native data given appropriate viewer code. It is also possible to use the generic model as a guide for creating generic YAML data structures for processing arbitrary YAML data.
It is impossible to implement concrete generic APIs directly using the native model, because of the differences between the native data types that may be used to represent each type family. To overcome this problem, the generic model provides a view of the value that is independent of the native data type chosen, using the concept of a format.
It may be possible to write a string value of a scalar 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 format.
A format defines a way to write the values of a scalar type family as Unicode strings. Using formats allows generic YAML APIs to be implemented in terms of such strings and still allow handling of arbitrary native data.
namedefinitionregexpFormats are an extension required by the generic model, and are not part of the native model. Hence, when constructing native data structures from YAML data, format need not be preserved. For example, a YAML integer node should be loaded to a native integer data type, discarding the information that the integer was serialized in hex format.
Each type family used for scalar nodes has associated 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 format.
Type families used for collection nodes do not have any associated formats.
implicit
formatsexplicit
formatscanonical
formatcanonical 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 the generic model, each scalar node has an associated format that is one of those defined by the node's type family. Collection nodes do not have an associated format.
The value of generic scalar nodes is a Unicode string that is a representation of the appropriate native value using the node's format.
To allow for YAML to be communicated as a sequence of events, an ordered tree structure must be used instead of a graph. This section describes an extension to the generic model where the graph is flattened and ordered to provide a serial interface. The resulting tree-structured model imposes a linear ordering and uses several constructs that are not part of the generic model. Applications constructing a native binding from the serial model should not use these additional constructs and the imposed ordering for the preservation of important data.
To lay out graph nodes as a tree structure, a mechanism is needed to manage duplicate occurrences. This is solved using an additional node kind, alias. The first occurrence of a node is represented using a serial node of the appropriate kind. Subsequent occurrences of either a collection or a scalar are represented by an alias.
All nodes in the serial model have the following properties in addition to the properties defined in the generic model:
parentanchorNote that when a serial node is converted to a generic node, the anchor, if any, is not converted. Likewise the parent property and the alias kind are not preserved as the node may participate in several collections.
The alias serial node represents subsequent occurrences of a scalar or collection in the serialization. Like all serial nodes, an alias node has a parent and an anchor property. In addition, an anchor node has a single additional property:
referentWhen an alias is converted into a generic node it becomes a subsequent occurrence of its referent's generic node.
A pair is an ordered set of two serial nodes. The first member of the set is the key and the second member of the set is the value.
Mapping serial nodes represent the first occurrence of a mapping in a given serialization. The value of mapping serial nodes is an ordered set of node pairs.
When a mapping serial node is converted into a generic 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 association 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 serial node is put into a single
linear sequence within a given document through the mapping pair
ordering. With the composition of collections, this ordering
becomes total. 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 and y are nodes within a sequence, and x appears
before y.
x is a key and y is a value in a
given pair.
x and y are nodes in two pairs within a mapping, 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.
To enhance readability, a YAML serialization extends the serial model with syntax styles, comments and directives. Although the parser may provide this information, applications should take care not to use these features to encode information found in a native binding.
The serial node is extended with a style property that can have different values depending upon its kind.
scalar stylecollection
styleThe 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 inside a scalar node value.
commentAttached to each document is a document directive section.
directive sectionFollowing are the syntax productions for the YAML serialization.
Characters are the basis for a serialized version of a YAML document. Below is a general definition of a character followed by several characters that have specific meaning in particular contexts.
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.
[001] |
printable_char |
::= |
#x9 |
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 serialization 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.
[002] |
byte_order_mark |
::= |
#xFEFF |
Indicators are special characters that are used to describe the structure of a YAML document.
[003] |
sequence_entry_indicator |
::= |
'-' |
||
[004] |
mapping_entry_separator |
::= |
':' |
||
[005] |
sequence_flow_start |
::= |
'[' |
||
[006] |
sequence_flow_end |
::= |
']' |
||
[007] |
mapping_flow_start |
::= |
'{' |
||
[008] |
mapping_flow_end |
::= |
'}' |
||
[009] |
collect_line_separator |
::= |
',' |
||
[010] |
top_key_indicator |
::= |
'?' |
||
[011] |
alias_indicator |
::= |
'*' |
||
[012] |
anchor_indicator |
::= |
'&' |
||
[013] |
transfer_indicator |
::= |
'!' |
||
[014] |
literal_indicator |
::= |
'|' |
||
[015] |
folded_indicator |
::= |
'>' |
||
[016] |
single_quote |
::= |
''' |
||
[017] |
double_quote |
::= |
'"' |
||
[018] |
throwaway_indicator |
::= |
'#' |
Indicators can be grouped into two categories. The '-' , ':', ',', '?' and '#' space indicators are always followed
by a white space character (space, tab or
line break). If followed by any
other character, they are taken to be normal content characters.
The remaining indicators are taken to be indicators even if
followed by a non-space character.
[019] |
space_indicators |
::= |
sequence_entry_indicator |
||
[020] |
non_space_indicators |
::= |
sequence_flow_start |
The Unicode standard defines the following line break characters.
[021] |
line_feed |
::= |
#xA |
||
[022] |
carriage_return |
::= |
#xD |
||
[023] |
next_line |
::= |
#x85 |
||
[024] |
line_separator |
::= |
#x2028 |
||
[025] |
paragraph_separator |
::= |
#x2029 |
||
[026] |
line_break_char |
::= |
line_feed |
Line breaks can be grouped into two categories. Specific line breaks have well-defined semantics 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 comment 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.
[027] |
generic_break |
::= |
( carriage_returngreedy |
||
[028] |
specific_break |
::= |
line_separator |
||
[029] |
any_break |
::= |
generic_break |
This section includes several common character range definitions.
[030] |
flow_char |
::= |
printable_char |
||
[031] |
flow_space |
::= |
#x20 | #x9 |
||
[032] |
flow_non_space |
::= |
flow_char |
||
[033] |
flow_non_ascii |
::= |
flow_char |
||
[034] |
ascii_letter |
::= |
[#x41-#x5A] |
||
[035] |
non_zero_digit |
::= |
[#x31-#x39] |
||
[036] |
decimal_digit |
::= |
[#x30-#x39] |
||
[037] |
hex_digit |
::= |
decimal_digit |
||
[038] |
word_char |
::= |
decimal_digit |
Serialized YAML uses text lines to convey structure. This requires special processing rules for white space (space and tab).
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.
[039] |
indent(n) |
::= |
#x20 x n |
||
[040] |
indent(<n) |
::= |
indent(m) |
m such
that m < n */ |
|
[041] |
indent(<=n) |
::= |
indent(m) |
m such
that m <= n */ |
Since the YAML serialization depends upon indentation level to
delineate blocks, additional productions are a function of an
integer, based on the production(any) is used; it is a shorthand for
"production(n) for some specific value of
n".
Throwaway comments have no effect whatsoever on the serial, generic, or native 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 to the end of a line. It
consists of white spaces, optionally followed by a '#' indicators, a white
space character, and arbitrary comment characters to the end of the
line.
Outside text content, empty lines or lines containing only white
space are taken to be implicit throwaway comment lines. Lines
containing indentation followed by '#' and comment
characters are taken to be explicit throwaway comment lines.
A throwaway comment may appear before a document node or following any node. A throwaway comment may not appear inside a scalar node, but may precede or follow it.
[042] |