YAML은 마크업 언어가 아니다(YAML™) 버전 1.2

개정판 1.2.2 (2021-10-01)

Copyright presently by YAML Language Development Team1
Copyright 2001-2009 by Oren Ben-Kiki, Clark Evans, Ingy döt Net

이 문서는 수정하지 않는다는 조건하에 자유롭게 복사할 수 있습니다.

이 문서의 상태

이 문서는 YAML 명세 v1.2.2입니다. 이는 YAML 1.2 데이터 언어를 정의합니다. YAML 명세 v1.2에서 규범적 변경 사항은 없습니다. 이 개정판의 주된 목적은 오류를 수정하고 명확성을 더하는 것입니다.

이 개정판은 또한 YAML 언어 개발 프로세스를 더 개방적이고, 더 투명하며, 사람들이 더 쉽게 기여할 수 있도록 만들고자 합니다. 입력 형식은 이제 DocBook 대신 Markdown이며, 이미지는 독점 드로잉 소프트웨어가 아니라 일반 텍스트 LaTeX 파일로 만들어집니다. 명세의 모든 소스 콘텐츠는 공개적으로 호스팅됩니다2.

이전 YAML 명세3는 12년 전에 공개되었습니다. 그 기간 동안 YAML의 인기는 크게 성장했습니다. 언어를 개선하고 사용자의 필요와 기대에 맞게 성장시키기 위한 노력이 계속되고 있습니다. 이 명세 개정판은 YAML에 실제 변경을 가하지는 않지만, 언어가 발전하고 현대성을 유지하기 위한 프로세스를 시작합니다.

YAML 명세는 그렇게 단순해 보이는 것치고는 지나치게 복잡하다고 여겨지는 경우가 많습니다. YAML은 소프트웨어 구성에 자주 사용되지만, 예전부터 지금까지 완전한 데이터 직렬화 언어였습니다. 향후 YAML 계획은 구현자를 위한 개발 프로세스를 단순화하는 동시에, 언어와 생태계를 더 강력하고 신뢰할 수 있게 만드는 데 초점을 둡니다.

이 명세 개정판은 정보 제공 변경으로만 범위를 제한하지만, YAML 프레임워크 구현자와 YAML 언어 사용자를 안내하기 위한 동반 문서가 있습니다. 이 문서는 이 명세의 공개 개정판 사이에서도 계속 발전하고 확장될 수 있습니다.

참조:

초록

YAML™(“camel”과 운이 맞음)은 사람이 읽기 쉽고, 여러 언어에서 사용할 수 있으며, Unicode 기반인 데이터 직렬화 언어로, 동적 프로그래밍 언어의 일반적인 네이티브 데이터 타입을 중심으로 설계되었습니다. 구성 파일부터 인터넷 메시징, 객체 영속화, 데이터 감사와 시각화에 이르는 프로그래밍 요구에 폭넓게 유용합니다. 문자에 대한 Unicode 표준4과 함께, 이 명세는 YAML 버전 1.2를 이해하고 YAML 정보를 처리하는 프로그램을 만드는 데 필요한 모든 정보를 제공합니다.

목차

제1장. YAML 소개

YAML(“YAML Ain’t Markup Language”의 재귀 약어)은 사람이 사용하기 쉽고 일상적인 공통 작업에서 현대 프로그래밍 언어와 잘 동작하도록 설계된 데이터 직렬화 언어입니다. 이 명세는 YAML 언어와 이를 뒷받침하는 개념에 대한 소개이기도 하며, YAML을 처리하는 애플리케이션을 개발하는 데 필요한 정보에 대한 완전한 명세이기도 합니다.

개방적이고 상호 운용 가능하며 쉽게 이해할 수 있는 도구는 컴퓨팅을 크게 발전시켜 왔습니다. YAML은 처음부터 데이터를 다루는 사람들에게 유용하고 친숙하도록 설계되었습니다. YAML은 Unicode 인쇄 가능 문자를 사용하며, 그중 일부는 구조적 정보를 제공하고 나머지는 데이터 자체를 담습니다. YAML은 구조 문자의 양을 최소화하고 데이터가 자연스럽고 의미 있는 방식으로 드러나도록 함으로써 고유한 깔끔함을 달성합니다. 예를 들어, 들여쓰기는 구조에 사용할 수 있고, 콜론은 키/값 쌍을 구분하며, 대시는 “글머리표” 목록을 만드는 데 사용됩니다.

데이터 구조에는 여러 종류가 있지만, 모두 세 가지 기본 원시 요소, 즉 매핑(해시/딕셔너리), 시퀀스(배열/목록), 스칼라 (문자열/숫자)로 충분히 표현할 수 있습니다. YAML은 이러한 원시 요소를 활용하고 간단한 타입 시스템과 별칭 메커니즘을 더하여, 어떤 네이티브 데이터 구조도 직렬화할 수 있는 완전한 언어를 형성합니다. 대부분의 프로그래밍 언어가 데이터 직렬화에 YAML을 사용할 수 있지만, YAML은 세 가지 기본 원시 요소를 중심으로 근본적으로 구축된 언어와 함께 사용할 때 특히 뛰어납니다. 여기에는 JavaScript, Perl, PHP, Python, Ruby와 같은 일반적인 동적 언어가 포함됩니다.

프로그래밍을 위한 언어는 수백 가지가 있지만, 데이터를 저장하고 전송하기 위한 언어는 몇 가지에 불과합니다. YAML의 잠재력은 사실상 무한하지만, YAML은 구성 파일, 로그 파일, 프로세스 간 메시징, 언어 간 데이터 공유, 객체 영속화, 복잡한 데이터 구조의 디버깅과 같은 일반적인 사용 사례에 잘 맞도록 특별히 만들어졌습니다. 데이터를 쉽게 보고 이해할 수 있으면, 프로그래밍은 더 단순한 작업이 됩니다.

1.1. 목표

YAML의 설계 목표는 우선순위가 높은 순서대로 다음과 같습니다.

  1. YAML은 사람이 쉽게 읽을 수 있어야 합니다.
  2. YAML 데이터는 프로그래밍 언어 사이에서 이식 가능해야 합니다.
  3. YAML은 동적 언어의 네이티브 데이터 구조와 맞아야 합니다.
  4. YAML은 일반 도구를 지원하기 위한 일관된 모델을 가져야 합니다.
  5. YAML은 단일 패스 처리를 지원해야 합니다.
  6. YAML은 표현력이 풍부하고 확장 가능해야 합니다.
  7. YAML은 구현하고 사용하기 쉬워야 합니다.

1.2. YAML 역사

YAML 1.0 명세는 yaml-core 메일링 리스트5를 통한 3년간의 공동 설계 작업 끝에, Clark Evans, Oren Ben-Kiki, Ingy döt Net이 2004년 초에 발표했습니다. 이 프로젝트는 처음에 Clark과 Oren의 SML-DEV6 메일링 리스트( XML 단순화를 위한 작업)와 Ingy의 Perl용 일반 텍스트 직렬화 모듈7 작업에 뿌리를 두고 있었습니다. 이 언어는 그보다 앞선 많은 다른 기술과 형식에서 많은 영감을 받았습니다.

최초의 YAML 프레임워크는 2001년에 Perl로 작성되었고, Ruby는 2003년에 핵심 언어 배포판의 일부로 YAML 프레임워크를 제공한 최초의 언어였습니다.

YAML 1.18 명세는 2005년에 발표되었습니다. 이 무렵 개발자들은 JSON9을 알게 되었습니다. 순전히 우연히도 JSON은 (구문적으로도 의미적으로도) 거의 완전한 YAML의 하위 집합이었습니다.

2006년에 Kyrylo Simonov는 PyYAML10과 LibYAML11을 만들었습니다. 여러 프로그래밍 언어의 많은 YAML 프레임워크가 LibYAML 위에 구축되어 있으며, 많은 다른 구현은 PyYAML을 견고한 참조 구현으로 삼아 왔습니다.

YAML 1.23 명세는 2009년에 발표되었습니다. 주된 초점은 YAML을 JSON의 엄격한 상위 집합으로 만드는 것이었습니다. 또한 문제가 많았던 여러 암시적 타이핑 권고 사항도 제거했습니다.

1.2 명세가 공개된 이후 YAML 채택은 계속 증가했고, 많은 대규모 프로젝트가 YAML을 주요 인터페이스 언어로 사용하고 있습니다. 2020년에 새로운 YAML 언어 설계 팀이 YAML 언어와 명세의 개선을 논의하고, 사용자와 사용 사례의 필요와 기대를 더 잘 충족하기 위해 정기적으로 회의를 시작했습니다.

2021년 10월에 발표된 이 YAML 1.2.2 명세는 YAML의 새로워진 개발 여정의 첫걸음입니다. YAML은 그 어느 때보다 인기가 높아졌지만, 잠재력을 완전히 발휘하려면 해결해야 할 것들이 아직 많이 남아 있습니다. YAML 설계 팀은 YAML을 가능한 한 훌륭하게 만드는 데 집중하고 있습니다.

1.3. 용어

이 문서에서 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, “OPTIONAL”이라는 핵심 단어는 RFC 211912에 설명된 대로 해석해야 합니다.

이 문서의 나머지 구성은 다음과 같습니다. 2장은 YAML의 주요 기능을 간략히 미리 보여 줍니다. 3장은 YAML 정보 모델과 이 모델 및 YAML 텍스트 형식 사이를 변환하는 프로세스를 설명합니다. 문서의 대부분을 차지하는 4장, 5장, 6장, 7장, 8장, 9장은 이 텍스트 형식을 형식적으로 정의합니다. 마지막으로 10장은 기본 YAML 스키마를 권장합니다.

제2장. 언어 개요

이 절은 YAML의 표현력을 빠르게 엿볼 수 있게 합니다. 처음 읽는 사람이 모든 예제를 완전히 이해할 것으로 기대하지는 않습니다. 오히려 이러한 예시는 명세의 나머지 부분을 위한 동기 부여로 사용됩니다.

2.1. 컬렉션

YAML의 블록 컬렉션은 들여쓰기를 범위에 사용하고 각 항목을 자체 줄에서 시작합니다. 블록 시퀀스는 각 항목을 대시와 공백(“- ”)으로 표시합니다. 매핑은 콜론과 공백(“: ”)을 사용하여 각 키/값 쌍을 표시합니다. 주석은 옥토소프(“hash”, “sharp”, “pound” 또는 “number sign”이라고도 함 - “#”)로 시작합니다.

예제 2.1 스칼라의 시퀀스(야구 선수)

- Mark McGwire
- Sammy Sosa
- Ken Griffey

예제 2.2 스칼라를 스칼라에 매핑(선수 통계)

hr:  65    # Home runs
avg: 0.278 # Batting average
rbi: 147   # Runs Batted In

예제 2.3 스칼라를 시퀀스에 매핑(각 리그의 야구 클럽)

american:
- Boston Red Sox
- Detroit Tigers
- New York Yankees
national:
- New York Mets
- Chicago Cubs
- Atlanta Braves

예제 2.4 매핑의 시퀀스(선수 통계)

-
  name: Mark McGwire
  hr:   65
  avg:  0.278
-
  name: Sammy Sosa
  hr:   63
  avg:  0.288

YAML에는 흐름 스타일도 있으며, 들여쓰기 대신 명시적인 표시자를 사용해 범위를 나타냅니다. 흐름 시퀀스는 대괄호 안에 쉼표로 구분된 목록으로 작성됩니다. 비슷한 방식으로, 흐름 매핑은 중괄호를 사용합니다.

예제 2.5 시퀀스의 시퀀스

- [name        , hr, avg  ]
- [Mark McGwire, 65, 0.278]
- [Sammy Sosa  , 63, 0.288]

예제 2.6 매핑의 매핑

Mark McGwire: {hr: 65, avg: 0.278}
Sammy Sosa: {
    hr: 63,
    avg: 0.288,
 }

2.2. 구조

YAML은 세 개의 대시(“---”)를 사용하여 지시문과 문서 콘텐츠를 구분합니다. 이는 지시문이 없을 때 문서의 시작을 알리는 역할도 합니다. 세 개의 점( “...”)은 통신 채널에서 사용할 수 있도록 새 문서를 시작하지 않고 문서의 끝을 나타냅니다.

예제 2.7 스트림 안의 두 문서(각각 앞에 주석 포함)

# Ranking of 1998 home runs
---
- Mark McGwire
- Sammy Sosa
- Ken Griffey

# Team ranking
---
- Chicago Cubs
- St Louis Cardinals

예제 2.8 경기의 실시간 진행 피드

---
time: 20:03:20
player: Sammy Sosa
action: strike (miss)
...
---
time: 20:03:47
player: Sammy Sosa
action: grand slam
...

반복되는 노드(객체)는 먼저 앵커로 식별되며(앰퍼샌드 - “&”로 표시), 이후에는 별칭으로 표시됩니다(별표 - “*”로 참조).

예제 2.9 두 개의 주석이 있는 단일 문서

---
hr: # 1998 hr ranking
- Mark McGwire
- Sammy Sosa
# 1998 rbi ranking
rbi:
- Sammy Sosa
- Ken Griffey

예제 2.10 “Sammy Sosa”에 대한 노드가 이 문서에 두 번 나타남

---
hr:
- Mark McGwire
# Following node labeled SS
- &SS Sammy Sosa
rbi:
- *SS # Subsequent occurrence
- Ken Griffey

물음표와 공백(“? ”)은 복합 매핑 키를 나타냅니다. 블록 컬렉션 안에서 키/값 쌍은 대시, 콜론 또는 물음표 바로 뒤에서 시작할 수 있습니다.

예제 2.11 시퀀스 간 매핑

? - Detroit Tigers
  - Chicago cubs
: - 2001-07-23

? [ New York Yankees,
    Atlanta Braves ]
: [ 2001-07-02, 2001-08-12,
    2001-08-14 ]

예제 2.12 간결한 중첩 매핑

---
# Products purchased
- item    : Super Hoop
  quantity: 1
- item    : Basketball
  quantity: 4
- item    : Big Shoes
  quantity: 1

2.3. 스칼라

스칼라 콘텐츠는 블록 표기법으로 작성할 수 있으며, 모든 줄바꿈이 의미를 갖는 리터럴 스타일 (“|”로 표시)을 사용할 수 있습니다. 또는 접힌 스타일(“>”로 표시)로 작성할 수 있는데, 이 경우 각 줄바꿈은 접혀서 공백이 됩니다. 단, 그것이 빈 줄이나 더 많이 들여쓴 줄을 끝낼 때는 예외입니다.

예제 2.13 리터럴에서는 줄바꿈이 보존됨

# ASCII Art
--- |
  \//||\/||
  // ||  ||__

예제 2.14 접힌 스칼라에서는 줄바꿈이 공백이 됨

--- >
  Mark McGwire's
  year was crippled
  by a knee injury.

예제 2.15 접힌 줄바꿈은 “더 많이 들여쓴” 줄과 빈 줄에서 보존됨

--- >
 Sammy Sosa completed another
 fine season with great stats.

   63 Home Runs
   0.288 Batting Average

 What a year!

예제 2.16 들여쓰기가 범위를 결정함

name: Mark McGwire
accomplishment: >
  Mark set a major league
  home run record in 1998.
stats: |
  65 Home Runs
  0.278 Batting Average

YAML의 흐름 스칼라에는 일반 스타일(지금까지의 대부분 예제)과 두 가지 인용 스타일이 포함됩니다. 큰따옴표 스타일은 이스케이프 시퀀스를 제공합니다. 작은따옴표 스타일은 이스케이프가 필요하지 않을 때 유용합니다. 모든 흐름 스칼라는 여러 줄에 걸칠 수 있으며, 줄바꿈은 항상 접힙니다.

예제 2.17 인용된 스칼라

unicode: "Sosa did fine.\u263A"
control: "\b1998\t1999\t2000\n"
hex esc: "\x0d\x0a is \r\n"

single: '"Howdy!" he cried.'
quoted: ' # Not a ''comment''.'
tie-fighter: '|\-*-/|'

예제 2.18 여러 줄 흐름 스칼라

plain:
  This unquoted scalar
  spans many lines.

quoted: "So does this
  quoted scalar.\n"

2.4. 태그

YAML에서 태그가 지정되지 않은 노드는 애플리케이션에 따라 타입이 부여됩니다. 이 명세의 예제는 일반적으로 failsafe 스키마의 seq, map, str 타입을 사용합니다. 몇몇 예제는 JSON 스키마의 int, float, null 타입도 사용합니다.

예제 2.19 정수

canonical: 12345
decimal: +12345
octal: 0o14
hexadecimal: 0xC

예제 2.20 부동 소수점

canonical: 1.23015e+3
exponential: 12.3015e+02
fixed: 1230.15
negative infinity: -.inf
not a number: .nan

예제 2.21 기타

null:
booleans: [ true, false ]
string: '012345'

예제 2.22 타임스탬프

canonical: 2001-12-15T02:59:43.1Z
iso8601: 2001-12-14t21:59:43.10-05:00
spaced: 2001-12-14 21:59:43.10 -5
date: 2002-12-14

명시적 타이핑은 느낌표(“!”) 기호를 사용하는 태그로 표시됩니다. 전역 태그는 URI이며, 핸들을 사용하는 태그 축약 표기법으로 지정할 수 있습니다. 애플리케이션별 로컬 태그도 사용할 수 있습니다.

예제 2.23 다양한 명시적 태그

---
not-date: !!str 2002-04-28

picture: !!binary |
 R0lGODlhDAAMAIQAAP//9/X
 17unp5WZmZgAAAOfn515eXv
 Pz7Y6OjuDg4J+fn5OTk6enp
 56enmleECcgggoBADs=

application specific tag: !something |
 The semantics of the tag
 above may be different for
 different documents.

예제 2.24 전역 태그

%TAG ! tag:clarkevans.com,2002:
--- !shape
  # Use the ! handle for presenting
  # tag:clarkevans.com,2002:circle
- !circle
  center: &ORIGIN {x: 73, y: 129}
  radius: 7
- !line
  start: *ORIGIN
  finish: { x: 89, y: 102 }
- !label
  start: *ORIGIN
  color: 0xFFEEBB
  text: Pretty vector drawing.

예제 2.25 순서 없는 집합

# Sets are represented as a
# Mapping where each key is
# associated with a null value
--- !!set
? Mark McGwire
? Sammy Sosa
? Ken Griffey

예제 2.26 순서 있는 매핑

# Ordered maps are represented as
# A sequence of mappings, with
# each mapping having one key
--- !!omap
- Mark McGwire: 65
- Sammy Sosa: 63
- Ken Griffey: 58

2.5. 전체 길이 예제

아래에는 두 개의 전체 길이 YAML 예제가 있습니다. 첫 번째는 샘플 송장이고, 두 번째는 샘플 로그 파일입니다.

예제 2.27 송장

--- !<tag: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.

예제 2.28 로그 파일

---
Time: 2001-11-23 15:01:42 -5
User: ed
Warning:
  This is an error message
  for the log file
---
Time: 2001-11-23 15:02:31 -5
User: ed
Warning:
  A slightly different error
  message.
---
Date: 2001-11-23 15:03:17 -5
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

제3장. 프로세스와 모델

YAML은 텍스트 형식이면서 동시에 어떤 네이티브 데이터 구조도 이 형식으로 제시하는 방법입니다. 따라서 이 명세는 두 가지 개념을 정의합니다. YAML 표현이라고 하는 데이터 객체의 클래스와, YAML 표현을 YAML 스트림이라고 부르는 일련의 문자로 제시하기 위한 구문입니다.

YAML 프로세서는 이러한 상호 보완적인 관점 사이에서 정보를 변환하는 도구입니다. YAML 프로세서는 애플리케이션이라고 하는 다른 모듈을 대신해 작업한다고 가정합니다. 이 장은 YAML 프로세서가 애플리케이션에 제공하거나 애플리케이션으로부터 받아야 하는 정보 구조를 설명합니다.

YAML 정보는 두 가지 방식으로 사용됩니다. 기계 처리와 사람이 읽는 소비입니다. 이 두 관점을 조화시키는 문제는 세 가지 구별되는 변환 단계, 즉 표현, 직렬화, 프레젠테이션으로 나누어 처리하는 것이 가장 좋습니다. 표현은 프로그래밍 환경 사이의 이식성을 달성하기 위해 YAML이 네이티브 데이터 구조를 어떻게 바라보는지를 다룹니다. 직렬화는 YAML 표현을 순차 접근 제약이 있는 직렬 형식으로 바꾸는 문제를 다룹니다. 프레젠테이션은 YAML 직렬화를 사람이 읽기 쉬운 방식으로 일련의 문자로 형식화하는 일을 다룹니다.

3.1. 프로세스

네이티브 데이터 구조와 문자 스트림 사이의 변환은 다음 그림과 같이 논리적으로 구별되는 여러 단계에서 수행되며, 각 단계는 잘 정의된 입력 및 출력 데이터 모델을 가집니다.

그림 3.1. 처리 개요

처리 개요

YAML 프로세서는 직렬화나 표현 단계를 노출할 필요가 없습니다. 프로세서는 네이티브 데이터 구조와 문자 스트림 사이를 직접 변환할 수 있습니다(위 그림의 덤프와 로드). 그러나 이러한 직접 변환은 네이티브 데이터 구조가 표현에서 사용할 수 있는 정보만으로 구성되도록 수행되어야 합니다. 특히 매핑 키 순서, 주석, 태그 핸들은 구성 중에 참조되어서는 안 됩니다.

3.1.1. 덤프

덤프는 네이티브 데이터 구조를 문자 스트림으로 변환하는 작업이며, 다음 세 단계로 수행됩니다.

네이티브 데이터 구조 표현

YAML은 세 가지 노드 종류를 사용하여 어떤 네이티브 데이터 구조도 표현합니다. 시퀀스 - 항목의 순서 있는 나열, 매핑 - 고유한 키에서 값으로의 순서 없는 연관, 그리고 스칼라 - 구조가 불투명하고 일련의 Unicode 문자로 제시할 수 있는 임의의 데이터입니다.

이러한 원시 요소들을 결합하면 방향 그래프 구조가 생성됩니다. 이 원시 요소들은 강력하면서도 익숙하기 때문에 선택되었습니다. 시퀀스는 Perl 배열 및 Python 목록에 대응하고, 매핑은 Perl 해시 테이블 및 Python 딕셔너리에 대응합니다. 스칼라는 문자열, 정수, 날짜 및 기타 원자적 데이터 타입을 나타냅니다.

각 YAML 노드는 자신의 종류와 콘텐츠 외에도, 데이터 타입을 지정하는 태그를 필요로 합니다. 타입 지정자는 전역 URI이거나 단일 애플리케이션 범위의 로컬 지정자입니다. 예를 들어, 정수는 YAML에서 스칼라와 전역 태그 “tag:yaml.org,2002:int”로 표현됩니다. 마찬가지로 특정 조직에 특화된 송장 객체는 매핑과 로컬 태그 “!invoice”로 함께 표현될 수 있습니다. 이 단순한 모델은 프로그래밍 언어와 독립적으로 어떤 데이터 구조도 표현할 수 있습니다.

표현 그래프 직렬화

이벤트 콜백 API와 같은 순차 접근 매체의 경우, YAML 표현은 순서 있는 트리로 직렬화되어야 합니다. YAML 표현에서 매핑 키는 순서가 없고 노드는 둘 이상의 곳에서 참조될 수 있으므로(둘 이상의 들어오는 “화살표”를 가질 수 있으므로), 직렬화 프로세스는 매핑 키에 순서를 부여하고, 주어진 노드에 대한 두 번째 및 이후 참조를 별칭이라고 하는 자리표시자로 바꾸어야 합니다. YAML은 이러한 직렬화 세부 사항이 어떻게 선택되는지는 지정하지 않습니다. 사람이 읽기 쉬운 키 순서와 앵커 이름을 정하는 것은 YAML 프로세서의 몫이며, 필요하다면 애플리케이션의 도움을 받을 수 있습니다. 이 프로세스의 결과인 YAML 직렬화 트리는 YAML 데이터의 단일 패스 처리를 위한 일련의 이벤트 호출을 생성하도록 순회될 수 있습니다.

직렬화 트리 제시

최종 출력 프로세스는 YAML 직렬화를 사람이 읽기 쉬운 방식으로 문자 스트림으로 제시하는 것입니다. 사람의 가독성을 최대화하기 위해, YAML은 단순한 데이터 저장의 최소 기능적 필요를 훨씬 넘어서는 풍부한 스타일 선택지를 제공합니다. 따라서 YAML 프로세서는 스트림을 만들 때 다양한 프레젠테이션 세부 사항을 도입해야 합니다. 예를 들어 노드 스타일 선택, 스칼라 콘텐츠 형식화 방법, 들여쓰기 양, 사용할 태그 핸들, 지정하지 않은 상태로 둘 노드 태그, 제공할 지시문 집합, 그리고 추가할 주석 등이 포함될 수 있습니다. 이 중 일부는 애플리케이션의 도움으로 수행될 수 있지만, 일반적으로 이 프로세스는 사용자의 선호에 따라 안내되어야 합니다.

3.1.2. 로드

로드는 문자 스트림에서 네이티브 데이터 구조를 가져오는 작업이며, 다음 세 단계로 수행됩니다.

프레젠테이션 스트림 파싱

파싱은 프레젠테이션의 역과정으로, 문자 스트림을 받아 직렬화 트리를 생성합니다. 파싱은 프레젠테이션 프로세스에서 도입된 모든 세부 사항을 버리고, 직렬화 트리만 보고합니다. 파싱은 형식이 잘못된 입력 때문에 실패할 수 있습니다.

표현 그래프 구성

구성은 직렬화 트리를 받아 표현 그래프를 생성합니다. 구성은 직렬화 프로세스에서 도입된 모든 세부 사항을 버리고, 표현 그래프만 생성합니다. 구성은 아래에 자세히 설명된 여러 이유 중 하나로 실패할 수 있습니다.

네이티브 데이터 구조 생성

최종 입력 프로세스는 YAML 표현으로부터 네이티브 데이터 구조를 생성하는 것입니다. 생성은 표현에서 사용할 수 있는 정보에만 기반해야 하며, 주석, 지시문, 매핑 키 순서, 노드 스타일, 스칼라 콘텐츠 형식, 들여쓰기 수준 등 추가적인 직렬화 또는 프레젠테이션 세부 사항에 기반해서는 안 됩니다. 생성은 필요한 네이티브 데이터 타입의 사용 불가능성 때문에 실패할 수 있습니다.

3.2. 정보 모델

이 절은 위 프로세스들의 결과에 대한 형식적 세부 사항을 지정합니다. 프로그래밍 언어와 구현 사이의 데이터 이식성을 최대화하기 위해, YAML 사용자는 직렬화 또는 프레젠테이션 속성과 YAML 표현의 일부인 속성 사이의 구분을 유념해야 합니다. 따라서 YAML 표현을 순차 접근 매체로 평탄화하기 위해 매핑 키에 순서를 부여하는 것이 필요하더라도, 이 직렬화 세부 사항은 애플리케이션 수준 정보를 전달하는 데 사용되어서는 안 됩니다. 비슷한 방식으로, 들여쓰기 기법과 노드 스타일 선택은 사람의 가독성을 위해 필요하지만, 이러한 프레젠테이션 세부 사항은 YAML 직렬화의 일부도 아니고 YAML 표현의 일부도 아닙니다. 직렬화와 프레젠테이션에 필요한 속성을 신중하게 분리함으로써, 애플리케이션 정보의 YAML 표현은 다양한 프로그래밍 환경 사이에서 일관되고 이식 가능해집니다.

다음 그림은 세 가지 정보 모델을 요약합니다. 채워진 화살표는 합성을, 빈 화살표는 상속을 나타내며, “1”과 “*”는 각각 “하나”와 “여러 개” 관계를 나타냅니다. 단일 “+”는 직렬화 세부 사항을, 이중 “++”는 프레젠테이션 세부 사항을 나타냅니다.

그림 3.2. 정보 모델

정보 모델

3.2.1. 표현 그래프

YAML의 네이티브 데이터 구조 표현은 태그가 지정된 노드들의 루트가 있고 연결된 방향 그래프입니다. “방향 그래프”란 노드 집합과 방향 간선(“화살표”)을 의미하며, 각 간선은 한 노드를 다른 노드에 연결합니다(형식적인 방향 그래프 정의13 참조). 모든 노드는 이러한 간선을 통해 루트 노드에서 도달 가능해야 합니다. YAML 그래프는 순환을 포함할 수 있으며, 하나의 노드가 둘 이상의 들어오는 간선을 가질 수 있다는 점에 유의하십시오.

다른 노드의 관점에서 정의되는 노드는 컬렉션이고, 다른 노드와 독립적인 노드는 스칼라입니다. YAML은 두 가지 컬렉션 노드 종류, 즉 시퀀스와 매핑을 지원합니다. 매핑 노드는 키가 순서가 없고 고유해야 하므로 다소 까다롭습니다.

그림 3.3. 표현 모델

표현 모델

3.2.1.1. 노드

YAML 노드는 단일 네이티브 데이터 구조를 표현합니다. 이러한 노드는 스칼라, 시퀀스 또는 매핑이라는 세 가지 종류 중 하나의 콘텐츠를 가집니다. 또한 각 노드는 콘텐츠가 가질 수 있는 가능한 값의 집합을 제한하는 태그를 가집니다.

스칼라

스칼라 노드의 콘텐츠는 0개 이상의 Unicode 문자 시리즈로 제시할 수 있는 불투명한 데이터입니다.

시퀀스

시퀀스 노드의 콘텐츠는 0개 이상의 노드로 이루어진 순서 있는 시리즈입니다. 특히 시퀀스는 동일한 노드를 한 번 이상 포함할 수 있습니다. 심지어 자기 자신을 포함할 수도 있습니다.

매핑

매핑 노드의 콘텐츠는 키/값 노드 쌍의 순서 없는 집합이며, 각 키가 고유해야 한다는 제약이 있습니다. YAML은 노드에 대해 더 이상의 제약을 두지 않습니다. 특히 키는 임의의 노드일 수 있고, 같은 노드가 여러 키/값 쌍의 값으로 사용될 수 있으며, 매핑은 자기 자신을 키나 값으로 포함할 수도 있습니다.

3.2.1.2. 태그

YAML은 태그라고 하는 간단한 식별자로 네이티브 데이터 구조의 타입 정보를 표현합니다. 전역 태그는 URI이므로 모든 애플리케이션에서 전역적으로 고유합니다. “tag:” URI 스킴14은 모든 전역 YAML 태그에 권장됩니다. 반대로 로컬 태그는 단일 애플리케이션에 특화되어 있습니다. 로컬 태그는 “!”로 시작하며, URI가 아니고 전역적으로 고유할 것으로 기대되지 않습니다. YAML은 태그 표기를 덜 장황하게 만들기 위해 “TAG” 지시문을 제공하며, 로컬 태그에서 전역 태그로 쉽게 이동할 수도 있게 합니다. 이를 보장하기 위해 로컬 태그는 URI 문자 집합으로 제한되며 URI 문자 이스케이프를 사용합니다.

YAML은 같은 부분 문자열로 시작하는 서로 다른 태그 사이에 특별한 관계를 요구하지 않습니다. URI 프래그먼트(“#” 포함)로 끝나는 태그도 예외가 아니며, 같은 기본 URI를 공유하지만 프래그먼트 부분이 다른 태그는 서로 독립적인 다른 태그로 간주됩니다. 관례상 프래그먼트는 태그의 서로 다른 “변형”을 식별하는 데 사용되고, “/”는 중첩된 태그 “네임스페이스” 계층을 정의하는 데 사용됩니다. 그러나 이는 단지 관례일 뿐이며 각 태그는 자신만의 규칙을 사용할 수 있습니다. 예를 들어 Perl 태그는 네임스페이스 계층을 표현하기 위해 “::”를 사용할 수 있고, Java 태그는 “.”을 사용할 수 있습니다.

YAML 태그는 각 노드에 메타 정보를 연결하는 데 사용됩니다. 특히 각 태그는 예상되는 노드 종류(스칼라, 시퀀스 또는 매핑)를 지정해야 합니다. 스칼라 태그는 또한 동등성 테스트를 지원하기 위해 형식화된 콘텐츠를 정규 형식으로 변환하는 메커니즘을 제공해야 합니다. 더 나아가 태그는 검증을 위해 허용되는 콘텐츠 값의 집합, 태그 해석 메커니즘 또는 해당 태그의 모든 노드에 적용 가능한 기타 데이터와 같은 추가 정보를 제공할 수 있습니다.

3.2.1.3. 노드 비교

YAML 매핑은 키의 고유성을 요구하므로, 표현에는 노드의 동등성을 테스트하는 메커니즘이 포함되어야 합니다. YAML은 스칼라 콘텐츠를 형식화하는 여러 방법을 허용하기 때문에 이는 사소하지 않습니다. 예를 들어 정수 11은 “0o13”(8진수) 또는 “0xB” (16진수)로 작성될 수 있습니다. 두 표기법이 같은 매핑에서 키로 사용되면, 정수 형식을 인식하는 YAML 프로세서만이 중복 키를 오류로 올바르게 표시할 수 있습니다.

정규 형식

YAML은 모든 스칼라 태그가 어떤 형식화된 콘텐츠에 대해서도 정규 형식을 생성하는 메커니즘을 지정하도록 요구함으로써 스칼라 동등성의 필요를 지원합니다. 이 형식은 같은 콘텐츠를 제시하는 Unicode 문자열이며, 동등성 테스트에 사용할 수 있습니다.

동등성

두 노드가 같다고 하려면 같은 태그와 같은 콘텐츠를 가져야 합니다. 각 태그는 정확히 하나의 종류에 적용되므로, 이는 두 노드가 같으려면 같은 종류를 가져야 한다는 것을 의미합니다.

두 스칼라는 그 태그와 정규 형식이 문자 단위로 같을 때만 같습니다. 컬렉션의 동등성은 재귀적으로 정의됩니다.

두 시퀀스는 같은 태그와 길이를 가지고, 한 시퀀스의 각 노드가 다른 시퀀스의 대응하는 노드와 같을 때만 같습니다.

두 매핑은 같은 태그와 같은 키 집합을 가지고, 이 집합의 각 키가 두 매핑 모두에서 같은 값과 연결되어 있을 때만 같습니다.

서로 다른 URI 스킴은 URI의 동등성 테스트에 대해 서로 다른 규칙을 정의할 수 있습니다. YAML 프로세서가 그 모든 규칙을 알고 있다고 합리적으로 기대할 수 없으므로, 일관성을 보장하기 위해 태그를 단순한 문자 단위 비교로 처리해야 합니다. 이는 “tag:” URI 스킴이 정의한 비교 방법이기도 합니다. 따라서 YAML 스트림의 태그는 그러한 비교가 올바른 결과를 산출하도록 정규적인 방식으로 제시되어야 합니다.

노드가 (별칭을 통해) 자기 자신을 후손으로 갖는 경우, 해당 노드의 동등성을 결정하는 방식은 구현 정의입니다.

YAML 프로세서는 같은 스칼라를 동일한 것처럼 취급할 수 있습니다.

고유성

매핑의 키는 서로 같은 두 키가 없을 때 고유합니다. 당연히 동일한 노드는 항상 같다고 간주됩니다.

3.2.2. 직렬화 트리

직렬 API를 사용하여 YAML 표현을 표현하려면, 매핑 키에 순서를 부여하고, 이전에 만난 노드의 이후 출현을 나타내기 위해 별칭 노드를 사용해야 합니다. 이 프로세스의 결과는 직렬화 트리이며, 여기서 각 노드는 순서 있는 자식 집합을 가집니다. 이 트리는 직렬 이벤트 기반 API를 위해 순회될 수 있습니다. 직렬 인터페이스로부터 네이티브 데이터 구조를 생성할 때는 애플리케이션 데이터를 보존하기 위해 키 순서나 앵커 이름을 사용해서는 안 됩니다.

그림 3.4. 직렬화 모델

직렬화 모델

3.2.2.1. 매핑 키 순서

표현 모델에서 매핑 키에는 순서가 없습니다. 매핑을 직렬화하려면 그 키에 순서를 부여해야 합니다. 이 순서는 직렬화 세부 사항이며, 표현 그래프를 구성할 때 사용되어서는 안 됩니다(따라서 애플리케이션 데이터 보존에도 사용되어서는 안 됩니다). 노드 순서가 중요한 모든 경우에는 시퀀스를 사용해야 합니다. 예를 들어 순서 있는 매핑은 각 매핑이 하나의 키/값 쌍인 매핑의 시퀀스로 표현할 수 있습니다. YAML은 이 경우를 위해 편리한 간결한 표기법을 제공합니다.

3.2.2.2. 앵커와 별칭

표현 그래프에서 하나의 노드는 둘 이상의 컬렉션에 나타날 수 있습니다. 이러한 데이터를 직렬화할 때, 노드의 첫 번째 출현은 앵커로 식별됩니다. 이후의 각 출현은 이 앵커를 다시 참조하는 별칭 노드로 직렬화됩니다. 그 밖의 경우, 앵커 이름은 직렬화 세부 사항이며 구성이 완료되면 폐기됩니다. 직렬화된 이벤트로부터 표현 그래프를 구성할 때, 별칭 이벤트는 지정된 앵커를 가진 직렬화의 가장 최근 이벤트를 참조합니다. 따라서 앵커는 직렬화 안에서 고유할 필요가 없습니다. 또한 앵커는 이를 참조하는 별칭 노드를 반드시 가질 필요도 없습니다.

3.2.3. 프레젠테이션 스트림

YAML 프레젠테이션은 스트림 형태의 Unicode 문자이며, 스타일, 스칼라 콘텐츠 형식, 주석, 지시문 및 기타 프레젠테이션 세부 사항을 사용해 YAML 직렬화를 사람이 읽을 수 있는 방식으로 제시합니다. YAML은 같은 YAML 프레젠테이션 스트림 안에 여러 직렬화 트리를 포함할 수 있으며, 이들은 마커로 구분된 일련의 문서로 나타납니다.

그림 3.5. 프레젠테이션 모델

프레젠테이션 모델

3.2.3.1. 노드 스타일

각 노드는 자신의 종류에 따라 어떤 스타일로 제시됩니다. 노드 스타일은 프레젠테이션 세부 사항이며, 직렬화 트리나 표현 그래프에는 반영되지 않습니다. 스타일에는 두 그룹이 있습니다. 블록 스타일은 들여쓰기를 사용해 구조를 나타냅니다. 반대로 흐름 스타일은 명시적인 표시자에 의존합니다.

YAML은 풍부한 스칼라 스타일 집합을 제공합니다. 블록 스칼라 스타일에는 리터럴 스타일과 접힌 스타일이 포함됩니다. 흐름 스칼라 스타일에는 일반 스타일과 두 가지 인용 스타일, 즉 작은따옴표 스타일과 큰따옴표 스타일이 포함됩니다. 이러한 스타일은 표현력과 가독성 사이의 다양한 절충을 제공합니다.

일반적으로 블록 시퀀스와 매핑은 다음 줄에서 시작합니다. 일부 경우 YAML은 더 간결한 표기법을 위해 중첩된 블록 컬렉션이 같은 줄에서 시작하는 것도 허용합니다. 또한 YAML은 흐름 시퀀스 안에 중첩된, 단일 키/값 쌍을 가진 흐름 매핑을 위한 간결한 표기법을 제공합니다. 이는 자연스러운 “순서 있는 매핑” 표기법을 가능하게 합니다.

그림 3.6. 종류/스타일 조합

종류/스타일 조합

3.2.3.2. 스칼라 형식

YAML은 스칼라가 여러 형식으로 제시될 수 있도록 허용합니다. 예를 들어 정수 “11”은 “0xB”로도 작성될 수 있습니다. 태그는 동등성 테스트에 사용할 수 있도록 형식화된 콘텐츠를 정규 형식으로 변환하는 메커니즘을 지정해야 합니다. 노드 스타일과 마찬가지로 형식은 프레젠테이션 세부 사항이며, 직렬화 트리와 표현 그래프에는 반영되지 않습니다.

3.2.3.3. 주석

주석은 프레젠테이션 세부 사항이며, 직렬화 트리나 표현 그래프에 어떤 영향도 주어서는 안 됩니다. 특히 주석은 특정 노드와 연결되지 않습니다. 주석의 일반적인 목적은 파일의 인간 유지보수자들 사이에서 의사소통하는 것입니다. 전형적인 예는 구성 파일의 주석입니다. 주석은 스칼라 내부에 나타나서는 안 되지만, 컬렉션 안의 그러한 스칼라 사이에 끼어들 수 있습니다.

3.2.3.4. 지시문

각 문서는 지시문 집합과 연결될 수 있습니다. 지시문은 이름과 선택적인 매개변수 시퀀스를 가집니다. 지시문은 YAML 프로세서에 대한 명령이며, 다른 모든 프레젠테이션 세부 사항과 마찬가지로 YAML 직렬화 트리나 표현 그래프에는 반영되지 않습니다. 이 YAML 버전은 “YAML”과 “TAG”라는 두 지시문을 정의합니다. 다른 모든 지시문은 YAML의 향후 버전을 위해 예약되어 있습니다.

3.3. 로딩 실패 지점

YAML 스트림에서 네이티브 데이터 구조를 로드하는 프로세스에는 여러 잠재적 실패 지점이 있습니다. 문자 스트림이 형식이 잘못되었을 수 있고, 별칭이 식별되지 않았을 수 있으며, 지정되지 않은 태그가 해석 불가능할 수 있고, 태그가 인식되지 않을 수 있으며, 콘텐츠가 유효하지 않을 수 있고, 매핑 키가 고유하지 않을 수 있으며, 네이티브 타입이 사용 불가능할 수 있습니다. 이러한 각 실패는 불완전한 로딩으로 이어집니다.

부분 표현은 각 노드의 태그를 해석할 필요가 없으며, 형식화된 스칼라 콘텐츠의 정규 형식도 사용할 수 있을 필요가 없습니다. 이 약한 표현은 문서에서 사용된 타입에 대한 지식이 불완전한 경우에 유용합니다.

반대로 완전한 표현은 각 노드의 태그를 지정하고 형식화된 스칼라 콘텐츠의 정규 형식을 제공하여 동등성 테스트를 가능하게 합니다. 네이티브 데이터 구조를 생성하려면 완전한 표현이 필요합니다.

그림 3.7. 로딩 실패 지점

로딩 실패 지점

3.3.1. 올바른 형식의 스트림과 식별된 별칭

올바른 형식의 문자 스트림은 다음 장들에서 지정된 BNF 생성 규칙과 일치해야 합니다. 성공적인 로딩은 또한 각 별칭이 이전의 노드를 식별한 앵커를 참조해야 함을 요구합니다. YAML 프로세서는 형식이 잘못된 스트림과 식별되지 않은 별칭을 거부해야 합니다. YAML 프로세서는 입력의 특정 부분을 무시하는 등 구문 오류에서 복구할 수 있지만, 그러한 오류를 보고하는 메커니즘을 제공해야 합니다.

3.3.2. 해석된 태그

일반적으로 대부분의 태그는 문자 스트림에 명시적으로 지정되지 않습니다. 파싱 중에 명시적인 태그가 없는 노드에는 비특정 태그가 부여됩니다. 비-일반 스칼라에는 “!”, 그 밖의 모든 노드에는 “?”가 사용됩니다. 완전한 표현을 구성하려면 이러한 각 비특정 태그를 특정 태그로 해석해야 합니다. 이는 전역 태그일 수도 있고 로컬 태그일 수도 있습니다.

노드의 태그 해석은 다음 세 가지 매개변수에만 의존해야 합니다. (1) 노드의 비특정 태그, (2) 루트에서 해당 노드로 이어지는 경로, (3) 노드의 콘텐츠(따라서 종류). 별칭을 사용해 하나의 노드가 둘 이상의 출현을 가질 때, 태그 해석은 해당 노드의 첫 번째 (앵커가 지정된) 출현까지의 경로에만 의존해야 합니다.

해석은 주석, 들여쓰기, 노드 스타일 같은 프레젠테이션 세부 사항을 고려해서는 안 됩니다. 또한 해석은 노드의 콘텐츠 외에 다른 노드의 콘텐츠를 고려해서는 안 됩니다. 예외는 루트에서 해석되는 노드로 이어지는 경로 바로 위의 키 노드의 콘텐츠입니다. 마지막으로 해석은 컬렉션 안의 형제 노드의 콘텐츠나, 해석되는 키 노드와 연결된 값 노드의 콘텐츠를 고려해서는 안 됩니다.

이 규칙들은 태그 해석이 스트림에서 노드가 처음 발견되자마자, 일반적으로 그 콘텐츠가 파싱되기 전에 수행될 수 있도록 보장합니다. 또한 태그 해석은 비교적 적은 수의 이전에 파싱된 노드만 참조하면 됩니다. 따라서 대부분의 경우 단일 패스 프로세서에서 태그 해석은 가능하고 실용적입니다.

YAML 프로세서는 “!” 비특정 태그를 가진 노드를 그 종류에 따라 “tag:yaml.org,2002:seq”, “tag:yaml.org,2002:map” 또는 “tag:yaml.org,2002:str”로 해석해야 합니다. 이 태그 해석 관례는 YAML 문자 스트림 작성자가 태그 해석 프로세스를 사실상 “비활성화”할 수 있게 합니다. “!” 비특정 태그 속성을 명시적으로 지정하면, 해당 노드는 자신의 종류에 따라 “기본” 시퀀스, 매핑 또는 문자열로 해석됩니다.

애플리케이션별 태그 해석 규칙은 “?” 비특정 태그를 해석하는 데, 가장 흔하게는 일반 스칼라를 해석하는 데 제한되어야 합니다. 이러한 규칙은 정수, 부동 소수점, 타임스탬프 및 유사한 타입의 자동 해석을 제공하기 위해 정규 표현식 집합과 대조될 수 있습니다. 애플리케이션은 또한 포인트, 복소수 및 유사한 타입을 자동으로 해석하기 위해 매핑 노드의 콘텐츠를 예상되는 키 집합과 대조할 수 있습니다. “순서 있는 매핑”과 같은 해석된 시퀀스 노드 타입도 가능합니다.

그렇지만 태그 해석은 애플리케이션에 특화됩니다. 따라서 YAML 프로세서는 애플리케이션이 이러한 기본 태그 해석 규칙을 재정의하고 확장할 수 있는 메커니즘을 제공해야 합니다.

문서에 해석되지 않은 태그가 포함되어 있으면, YAML 프로세서는 완전한 표현 그래프를 구성할 수 없습니다. 이러한 경우 YAML 프로세서는 각 노드의 종류를 기반으로 하고 비특정 태그를 허용하여 부분 표현을 구성할 수 있습니다.

3.3.3. 인식되고 유효한 태그

노드가 유효하려면 YAML 프로세서가 인식하는 태그를 가져야 하며, 그 콘텐츠는 이 태그가 부과하는 제약을 만족해야 합니다. 문서에 인식되지 않은 태그 또는 유효하지 않은 콘텐츠를 가진 스칼라 노드가 포함되어 있으면, 부분 표현만 구성될 수 있습니다. 반대로 YAML 프로세서는 인식되지 않거나 유효하지 않은 컬렉션에 대해서도 항상 완전한 표현을 구성할 수 있습니다. 왜냐하면 컬렉션 동등성은 컬렉션의 데이터 타입에 대한 지식에 의존하지 않기 때문입니다. 그러나 그러한 완전한 표현은 네이티브 데이터 구조를 생성하는 데 사용할 수 없습니다.

3.3.4. 사용 가능한 태그

주어진 처리 환경에서는 특정 태그에 대응하는 사용 가능한 네이티브 타입이 존재하지 않을 수 있습니다. 노드의 태그가 사용 불가능하면, YAML 프로세서는 그 노드에 대한 네이티브 데이터 구조를 생성할 수 없습니다. 이 경우에도 완전한 표현은 구성될 수 있으며, 애플리케이션은 이 표현을 직접 사용하고자 할 수 있습니다.

제4장. 구문 관례

다음 장들은 매개변수화된 BNF 생성 규칙을 사용하여 YAML 문자 스트림의 구문을 형식적으로 정의합니다. 각 BNF 생성 규칙은 쉽게 참조할 수 있도록 이름과 번호를 모두 가집니다. 가능한 경우, 기본 구조는 이를 사용하는 더 복잡한 구조보다 먼저 “상향식” 방식으로 지정됩니다.

생성 규칙에는 두 패널을 나란히 배치한 형식으로 제시되는 예제가 함께 제공됩니다. 왼쪽은 YAML 예제이고, 오른쪽은 해당 예제의 대체 YAML 보기입니다. 오른쪽 보기는 가능한 경우 JSON을 사용합니다. 그렇지 않은 경우 JSON에 최대한 가까운 YAML 형식을 사용합니다.

4.1. 생성 규칙 구문

생성 규칙은 production-name ::= term 구문을 사용해 정의되며, 여기서 term은 다음 중 하나입니다.

원자 항
  • 따옴표로 묶인 문자열("abc")로, 해당 문자 연결과 일치합니다. 단일 문자는 보통 작은따옴표('a')로 작성합니다.
  • 16진수 숫자(x0A)로, 해당 Unicode 코드 지점의 문자와 일치합니다.
  • 16진수 숫자의 범위([x20-x7E])로, Unicode 코드 지점이 해당 범위 안에 있는 모든 문자와 일치합니다.
  • 생성 규칙의 이름(c-printable)으로, 해당 생성 규칙과 일치합니다.
전후방 탐색
  • [ lookahead = term ]은 term이 일치할 경우 빈 문자열과 일치합니다.
  • [ lookahead ≠ term ]은 term이 일치하지 않을 경우 빈 문자열과 일치합니다.
  • [ lookbehind = term ]은 term이 해당 줄의 이전 지점에서 시작해 현재 위치에서 끝나는 경우 빈 문자열과 일치합니다.
특수 생성 규칙
  • <start-of-line>은 줄의 시작에서 빈 문자열과 일치합니다.
  • <end-of-input>은 입력의 끝에서 빈 문자열과 일치합니다.
  • <empty>는 (항상) 빈 문자열과 일치합니다.
괄호로 묶인 항

그 내용을 일치시킵니다.

연결

term-one term-two이며, term-one 뒤에 term-two가 오는 것과 일치합니다.

대안

term-one | term-two이며, 가능하면 term-one과 일치하고, 그렇지 않으면 term-two와 일치합니다.

수량화된 항:
  • term?은 (term | <empty>)과 일치합니다.
  • term*은 (term term* | <empty>)과 일치합니다.
  • term+은 (term term*)과 일치합니다.

참고: 수량화된 항은 항상 탐욕적입니다.

우선순위의 순서는 괄호 묶기, 수량화, 연결, 대안 순입니다.

생성 규칙 정의의 일부 줄에는 다음과 같은 주석이 있을 수 있습니다.

production-a ::=
  production-b      # clarifying comment

이 주석들은 정보 제공용일 뿐입니다. 예를 들어 # not followed by non-ws char라는 주석은 특정 생성 규칙의 내용만으로는 명확하지 않을 수 있지만, 실제 생성 규칙이 설명된 대로 동작한다는 점을 알아두라는 뜻입니다.

4.2. 생성 규칙 매개변수

일부 생성 규칙은 이름 뒤 괄호 안에 매개변수를 가지며, 예를 들면 s-line-prefix(n,c)와 같습니다. 매개변수화된 생성 규칙은 각 매개변수에 고정값을 가진 (무한한) 생성 규칙 시리즈의 축약 표현입니다.

예를 들어, 이 생성 규칙은:

production-a(n) ::= production-b(n)

다음의 축약 표현입니다.

production-a(0) ::= production-b(0)
production-a(1) ::= production-b(1)
…

그리고 이 생성 규칙은:

production-a(n) ::=
  ( production-b(n+m) production-c(n+m) )+

다음의 축약 표현입니다.

production-a(0) ::=
    ( production-b(0) production-c(0) )+
  | ( production-b(1) production-c(1) )+
  | …
production-a(1) ::=
    ( production-b(1) production-c(1) )+
  | ( production-b(2) production-c(2) )+
  | …
…

매개변수는 다음과 같습니다.

들여쓰기: n 또는 m

0을 포함한 임의의 자연수일 수 있습니다. n은 -1일 수도 있습니다.

컨텍스트: c

이 매개변수는 생성 규칙이 주변 환경에 따라 동작을 조정할 수 있게 합니다. YAML은 블록 스타일과 흐름 스타일을 구분하는 두 그룹의 컨텍스트를 지원합니다.

다음 값 중 하나일 수 있습니다.

  • BLOCK-IN – 블록 컨텍스트 내부
  • BLOCK-OUT – 블록 컨텍스트 외부
  • BLOCK-KEY – 블록 키 컨텍스트 내부
  • FLOW-IN – 흐름 컨텍스트 내부
  • FLOW-OUT – 흐름 컨텍스트 외부
  • FLOW-KEY – 흐름 키 컨텍스트 내부
(블록) 촘핑: t

흐름 스칼라에 대한 줄바꿈 촘핑 동작입니다. 다음 값 중 하나일 수 있습니다.

  • STRIP – 모든 후행 줄바꿈 제거
  • CLIP – 첫 번째를 제외한 모든 후행 줄바꿈 제거
  • KEEP – 모든 후행 줄바꿈 유지

4.3. 생성 규칙 이름 지정 관례

생성 규칙 조합을 더 쉽게 따라갈 수 있도록, 생성 규칙 이름은 접두사 스타일 이름 지정 관례를 사용합니다. 각 생성 규칙에는 시작하고 끝나는 문자 유형에 따라 접두사가 부여됩니다.

e-

어떤 문자와도 일치하지 않는 생성 규칙입니다.

c-

특수 문자로 시작하고 끝나는 생성 규칙입니다.

b-

단일 줄바꿈과 일치하는 생성 규칙입니다.

nb-

줄바꿈이 아닌 문자로 시작하고 끝나는 생성 규칙입니다.

s-

공백 문자로 시작하고 끝나는 생성 규칙입니다.

ns-

공백이 아닌 문자로 시작하고 끝나는 생성 규칙입니다.

l-

완전한 줄과 일치하는 생성 규칙입니다.

X-Y-

X- 문자로 시작하고 Y- 문자로 끝나는 생성 규칙입니다. 여기서 X-와 Y-는 위 접두사 중 하나입니다.

X+, X-Y+

위와 같은 생성 규칙이지만, 일치한 콘텐츠의 들여쓰기 수준이 지정된 n 매개변수보다 크다는 추가 속성을 가집니다.

제5장. 문자 생성 규칙

5.1. 문자 집합

가독성을 보장하기 위해 YAML 스트림은 Unicode 문자 집합의 인쇄 가능 하위 집합만 사용합니다. 허용되는 문자 범위는 C0 제어 블록15 x00-x1F(허용되는 TAB x09, LF x0A, CR x0D 제외), DEL x7F, C1 제어 블록 x80-x9F(허용되는 NEL x85 제외), 대리 블록16 xD800-xDFFF, xFFFE 및 xFFFF를 명시적으로 제외합니다.

입력 시 YAML 프로세서는 이 인쇄 가능 하위 집합의 모든 문자를 허용해야 합니다.

출력 시 YAML 프로세서는 이 인쇄 가능 하위 집합의 문자만 생성해야 합니다. 이 집합 밖의 문자는 이스케이프 시퀀스를 사용하여 제시해야 합니다. 또한 허용된 문자 중 인쇄 불가능하다고 알려진 문자도 이스케이프해야 합니다.

참고: 이는 필수는 아닙니다. 완전한 구현에는 방대한 문자 속성 테이블이 필요하기 때문입니다.

[1] c-printable ::=
                         # 8 bit
    x09                  # Tab (\t)
  | x0A                  # Line feed (LF \n)
  | x0D                  # Carriage Return (CR \r)
  | [x20-x7E]            # Printable ASCII
                         # 16 bit
  | x85                  # Next Line (NEL)
  | [xA0-xD7FF]          # Basic Multilingual Plane (BMP)
  | [xE000-xFFFD]        # Additional Unicode Areas
  | [x010000-x10FFFF]    # 32 bit

JSON 호환성을 보장하기 위해 YAML 프로세서는 따옴표로 묶인 스칼라 안에서 모든 비-C0 문자를 허용해야 합니다. 가독성을 보장하기 위해, 출력 시 인쇄 불가능한 문자는 이러한 스칼라 안에서도 이스케이프해야 합니다.

참고: JSON 따옴표로 묶인 스칼라는 여러 줄에 걸치거나 탭을 포함할 수 없지만, YAML 따옴표로 묶인 스칼라는 가능합니다.

[2] nb-json ::=
    x09              # Tab character
  | [x20-x10FFFF]    # Non-C0-control characters

참고: 여기서 생성 규칙 이름 nb-json은 “non-break JSON compatible”을 의미합니다.

5.2. 문자 인코딩

이 명세에서 언급되는 모든 문자는 Unicode 코드 지점입니다. 이러한 각 코드 지점은 사용되는 문자 인코딩에 따라 하나 이상의 바이트로 작성됩니다. UTF-16에서 xFFFF를 초과하는 문자는 대리 쌍을 사용하여 네 바이트로 작성된다는 점에 유의하십시오.

문자 인코딩은 프레젠테이션 세부 사항이며, 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다.

입력 시 YAML 프로세서는 UTF-8 및 UTF-16 문자 인코딩을 지원해야 합니다. JSON 호환성을 위해 UTF-32 인코딩도 지원해야 합니다.

문자 스트림이 바이트 순서 표시로 시작하면, 문자 인코딩은 바이트 순서 표시가 나타내는 대로 간주됩니다. 그렇지 않으면 스트림은 ASCII 문자로 시작해야 합니다. 이를 통해 null(x00) 문자의 패턴으로 인코딩을 추론할 수 있습니다.

바이트 순서 표시는 임의의 문서 시작 부분에 나타날 수 있지만, 같은 스트림 안의 모든 문서는 같은 문자 인코딩을 사용해야 합니다.

JSON 호환성을 허용하기 위해, 바이트 순서 표시는 따옴표로 묶인 스칼라 안에서도 허용됩니다. 가독성을 위해 이러한 콘텐츠 바이트 순서 표시는 출력 시 이스케이프해야 합니다.

따라서 인코딩은 스트림의 처음 몇 바이트를 다음 표 행과 (순서대로) 일치시켜 추론할 수 있습니다.

Byte0 Byte1 Byte2 Byte3 인코딩
명시적 BOM x00 x00 xFE xFF UTF-32BE
ASCII 첫 문자 x00 x00 x00 any UTF-32BE
명시적 BOM xFF xFE x00 x00 UTF-32LE
ASCII 첫 문자 any x00 x00 x00 UTF-32LE
명시적 BOM xFE xFF UTF-16BE
ASCII 첫 문자 x00 any UTF-16BE
명시적 BOM xFF xFE UTF-16LE
ASCII 첫 문자 any x00 UTF-16LE
명시적 BOM xEF xBB xBF UTF-8
기본값 UTF-8

권장 출력 인코딩은 UTF-8입니다. 다른 인코딩을 사용하는 경우, 첫 번째 스트림 문자가 ASCII이더라도 명시적 바이트 순서 표시를 사용하는 것이 권장됩니다.

바이트 순서 표시와 Unicode 문자 인코딩 스킴에 대한 자세한 정보는 Unicode FAQ17를 참조하십시오.

[3] c-byte-order-mark ::= xFEFF

예제에서 바이트 순서 표시 문자는 “⇔”로 표시됩니다.

예제 5.1 바이트 순서 표시

⇔# Comment only.


# This stream contains no
# documents, only comments.

범례:

예제 5.2 유효하지 않은 바이트 순서 표시

- Invalid use of BOM
⇔
- Inside a document.

ERROR:
 A BOM must not appear
 inside a document.

5.3. 표시 문자

표시자는 특별한 의미를 가진 문자입니다.

”-”(x2D, 하이픈)은 블록 시퀀스 항목을 나타냅니다.

[4] c-sequence-entry ::= '-'

”?”(x3F, 물음표)는 매핑 키를 나타냅니다.

[5] c-mapping-key ::= '?'

”:”(x3A, 콜론)는 매핑 값을 나타냅니다.

[6] c-mapping-value ::= ':'

예제 5.3 블록 구조 표시자

sequence:
- one
- two
mapping:
  ? sky
  : blue
  sea : green

{ "sequence": [
    "one",
    "two" ],
  "mapping": {
    "sky": "blue",
    "sea": "green" } }

범례:

”,”(x2C, 쉼표)는 흐름 컬렉션 항목을 끝냅니다.

[7] c-collect-entry ::= ','

”[”(x5B, 왼쪽 대괄호)는 흐름 시퀀스를 시작합니다.

[8] c-sequence-start ::= '['

”]”(x5D, 오른쪽 대괄호)는 흐름 시퀀스를 끝냅니다.

[9] c-sequence-end ::= ']'

”{”(x7B, 왼쪽 중괄호)는 흐름 매핑을 시작합니다.

[10] c-mapping-start ::= '{'

”}”(x7D, 오른쪽 중괄호)는 흐름 매핑을 끝냅니다.

[11] c-mapping-end ::= '}'

예제 5.4 흐름 컬렉션 표시자

sequence: [ one, two, ]
mapping: { sky: blue, sea: green }

{ "sequence": [ "one", "two" ],
  "mapping":
    { "sky": "blue", "sea": "green" } }

범례:

”#”(x23, octothorpe, hash, sharp, pound, number sign)는 주석을 나타냅니다.

[12] c-comment ::= '#'

예제 5.5 주석 표시자

# Comment only.


# This stream contains no
# documents, only comments.

범례:

”&”(x26, 앰퍼샌드)는 노드의 앵커 속성을 나타냅니다.

[13] c-anchor ::= '&'

”*”(x2A, 별표)는 별칭 노드를 나타냅니다.

[14] c-alias ::= '*'

“!”(x21, 느낌표)는 노드 태그를 지정하는 데 사용됩니다. 이는 태그 지시문과 태그 속성에서 사용되는 태그 핸들을 나타내고, 로컬 태그를 나타내며, 비-일반 스칼라에 대한 비특정 태그로도 사용됩니다. 

[15] c-tag ::= '!'

예제 5.6 노드 속성 표시자

anchored: !local &anchor value
alias: *anchor

{ "anchored": !local &A1 "value",
  "alias": *A1 }

범례:

”|”(7C, 세로 막대)는 리터럴 블록 스칼라를 나타냅니다.

[16] c-literal ::= '|'

”>”(x3E, 보다 큼)는 접힌 블록 스칼라를 나타냅니다.

[17] c-folded ::= '>'

예제 5.7 블록 스칼라 표시자

literal: |
  some
  text
folded: >
  some
  text

{ "literal": "some\ntext\n",
  "folded": "some text\n" }

범례:

”'”(x27, 아포스트로피, 작은따옴표)는 작은따옴표 흐름 스칼라를 둘러쌉니다. 

[18] c-single-quote ::= "'"

”"”(x22, 큰따옴표)는 큰따옴표 흐름 스칼라를 둘러쌉니다.

[19] c-double-quote ::= '"'

예제 5.8 인용 스칼라 표시자

single: 'text'
double: "text"

{ "single": "text",
  "double": "text" }

범례:

”%”(x25, 퍼센트)는 지시문 줄을 나타냅니다.

[20] c-directive ::= '%'

예제 5.9 지시문 표시자

%YAML 1.2
--- text

"text"

범례:

“@”(x40, at)와 “`” (x60, 억음 악센트)는 향후 사용을 위해 예약되어 있습니다. 

[21] c-reserved ::=
    '@' | '`'

예제 5.10 예약된 표시자의 유효하지 않은 사용

commercial-at: @text
grave-accent: `text

ERROR:
 Reserved indicators can't
 start a plain scalar.

임의의 표시 문자:

[22] c-indicator ::=
    c-sequence-entry    # '-'
  | c-mapping-key       # '?'
  | c-mapping-value     # ':'
  | c-collect-entry     # ','
  | c-sequence-start    # '['
  | c-sequence-end      # ']'
  | c-mapping-start     # '{'
  | c-mapping-end       # '}'
  | c-comment           # '#'
  | c-anchor            # '&'
  | c-alias             # '*'
  | c-tag               # '!'
  | c-literal           # '|'
  | c-folded            # '>'
  | c-single-quote      # "'"
  | c-double-quote      # '"'
  | c-directive         # '%'
  | c-reserved          # '@' '`'

“[”, “]”, “{”, “}” 및 “,” 표시자는 흐름 컬렉션에서 구조를 나타냅니다. 따라서 여러 구성에서 모호성을 피하기 위해 일부 경우에는 금지됩니다. 이는 관련 생성 규칙에서 사례별로 처리됩니다.

[23] c-flow-indicator ::=
    c-collect-entry     # ','
  | c-sequence-start    # '['
  | c-sequence-end      # ']'
  | c-mapping-start     # '{'
  | c-mapping-end       # '}'

5.4. 줄바꿈 문자

YAML은 다음 ASCII 줄바꿈 문자를 인식합니다.

[24] b-line-feed ::= x0A

[25] b-carriage-return ::= x0D

[26] b-char ::=
    b-line-feed          # x0A
  | b-carriage-return    # X0D

폼 피드(x0C)를 포함한 다른 모든 문자는 줄바꿈이 아닌 문자로 간주됩니다. 여기에는 비-ASCII 줄바꿈, 즉 다음 줄(x85), 줄 구분자(x2028) 및 단락 구분자(x2029)도 포함된다는 점에 유의하십시오.

YAML 버전 1.1은 위의 비-ASCII 줄바꿈 문자를 지원했습니다. 그러나 JSON은 그렇지 않습니다. 따라서 JSON 호환성을 보장하기 위해, YAML은 버전 1.2부터 이를 줄바꿈이 아닌 문자로 취급합니다. 그러므로 버전 1.1 문서를 파싱하는 YAML 1.2 프로세서는 적절한 경고와 함께 이러한 줄바꿈을 줄바꿈이 아닌 문자로 처리해야 합니다. 

[27] nb-char ::=
  c-printable - b-char - c-byte-order-mark

줄바꿈은 시스템마다 다르게 해석되며 널리 사용되는 여러 형식을 가집니다.

[28] b-break ::=
    (
      b-carriage-return  # x0A
      b-line-feed
    )                    # x0D
  | b-carriage-return
  | b-line-feed

스칼라 콘텐츠 안의 줄바꿈은 YAML 프로세서에 의해 정규화되어야 합니다. 그러한 각 줄바꿈은 단일 줄바꿈 문자로 파싱되어야 합니다. 원래 줄바꿈 형식은 프레젠테이션 세부 사항이며, 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다. 

[29] b-as-line-feed ::=
  b-break

스칼라 콘텐츠 밖에서 YAML은 임의의 줄바꿈을 사용해 줄을 종료할 수 있도록 허용합니다.

[30] b-non-content ::=
  b-break

출력 시 YAML 프로세서는 가장 적절한 관례를 사용해 줄바꿈을 자유롭게 내보낼 수 있습니다.

예제에서 줄바꿈은 명확성을 위해 때때로 “↓” 글리프로 표시됩니다.

예제 5.11 줄바꿈 문자

|
  Line break (no glyph)
  Line break (glyphed)↓

"Line break (no glyph)\nLine break (glyphed)\n"

범례:

5.5. 공백 문자

YAML은 두 가지 공백 문자인 스페이스와 탭을 인식합니다.

[31] s-space ::= x20

[32] s-tab ::= x09

[33] s-white ::=
  s-space | s-tab

나머지 (인쇄 가능) 비-줄바꿈 문자는 공백이 아닌 문자로 간주됩니다.

[34] ns-char ::=
  nb-char - s-white

예제에서 탭 문자는 “→” 글리프로 표시됩니다. 스페이스 문자는 명확성을 위해 때때로 “·” 글리프로 표시됩니다.

예제 5.12 탭과 스페이스

# Tabs and spaces
quoted:·"Quoted →"
block:→|
··void main() {
··→printf("Hello, world!\n");
··}

{ "quoted": "Quoted \t",
  "block": "void main()
    {\n\tprintf(\"Hello, world!\\n\");\n}\n" }

범례:

5.6. 기타 문자

YAML 구문 생성 규칙은 다음 추가 문자 클래스를 사용합니다.

숫자를 위한 십진 숫자:

[35] ns-dec-digit ::=
  [x30-x39]             # 0-9

이스케이프 시퀀스를 위한 16진 숫자:

[36] ns-hex-digit ::=
    ns-dec-digit        # 0-9
  | [x41-x46]           # A-F
  | [x61-x66]           # a-f

ASCII 문자(알파벳) 문자:

[37] ns-ascii-letter ::=
    [x41-x5A]           # A-Z
  | [x61-x7A]           # a-z

식별자를 위한 단어(영숫자) 문자:

[38] ns-word-char ::=
    ns-dec-digit        # 0-9
  | ns-ascii-letter     # A-Z a-z
  | '-'                 # '-'

URI 명세18에 정의된, 태그를 위한 URI 문자입니다.

관례상 허용된 인쇄 가능 ASCII 문자를 제외한 모든 URI 문자는 먼저 UTF-8로 인코딩된 다음 각 바이트가 “%” 문자를 사용해 이스케이프됩니다. YAML 프로세서는 그러한 이스케이프 문자를 확장해서는 안 됩니다. 태그 문자는 아무 처리 없이 YAML 스트림에서 제시된 그대로 정확히 보존되고 비교되어야 합니다. 

[39] ns-uri-char ::=
    (
      '%'
      ns-hex-digit{2}
    )
  | ns-word-char
  | '#'
  | ';'
  | '/'
  | '?'
  | ':'
  | '@'
  | '&'
  | '='
  | '+'
  | '$'
  | ','
  | '_'
  | '.'
  | '!'
  | '~'
  | '*'
  | "'"
  | '('
  | ')'
  | '['
  | ']'

“!” 문자는 이름 있는 태그 핸들의 끝을 나타내는 데 사용되므로, 태그 축약에서의 사용은 제한됩니다. 또한 이러한 축약은 “[”, “]”, “{”, “}” 및 “,” 문자를 포함해서는 안 됩니다. 이러한 문자는 흐름 컬렉션 구조와 모호성을 일으킬 수 있습니다. 

[40] ns-tag-char ::=
    ns-uri-char
  - c-tag               # '!'
  - c-flow-indicator

5.7. 이스케이프 문자

모든 비-인쇄 가능 문자는 이스케이프되어야 합니다. YAML 이스케이프 시퀀스는 대부분의 현대 컴퓨터 언어에 공통적인 “\” 표기법을 사용합니다. 각 이스케이프 시퀀스는 적절한 Unicode 문자로 파싱되어야 합니다. 원래 이스케이프 시퀀스는 프레젠테이션 세부 사항이며, 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다.

이스케이프 시퀀스는 큰따옴표 스칼라에서만 해석된다는 점에 유의하십시오. 다른 모든 스칼라 스타일에서 “\” 문자는 특별한 의미가 없으며 비-인쇄 가능 문자는 사용할 수 없습니다.

[41] c-escape ::= '\'

YAML 이스케이프 시퀀스는 C의 이스케이프 시퀀스의 상위 집합입니다.

이스케이프된 ASCII null(x00) 문자.

[42] ns-esc-null ::= '0'

이스케이프된 ASCII 벨(x07) 문자.

[43] ns-esc-bell ::= 'a'

이스케이프된 ASCII 백스페이스(x08) 문자.

[44] ns-esc-backspace ::= 'b'

이스케이프된 ASCII 수평 탭(x09) 문자. 이는 줄의 시작이나 끝에서 선행 또는 후행 탭을 강제로 콘텐츠의 일부로 만들 때 유용합니다. 

[45] ns-esc-horizontal-tab ::=
  't' | x09

이스케이프된 ASCII 줄바꿈(x0A) 문자.

[46] ns-esc-line-feed ::= 'n'

이스케이프된 ASCII 수직 탭(x0B) 문자.

[47] ns-esc-vertical-tab ::= 'v'

이스케이프된 ASCII 폼 피드(x0C) 문자.

[48] ns-esc-form-feed ::= 'f'

이스케이프된 ASCII 캐리지 리턴(x0D) 문자.

[49] ns-esc-carriage-return ::= 'r'

이스케이프된 ASCII 이스케이프(x1B) 문자. 

[50] ns-esc-escape ::= 'e'

이스케이프된 ASCII 스페이스(x20) 문자. 이는 줄의 시작이나 끝에서 선행 또는 후행 스페이스를 강제로 콘텐츠의 일부로 만들 때 유용합니다. 

[51] ns-esc-space ::= x20

이스케이프된 ASCII 큰따옴표(x22).

[52] ns-esc-double-quote ::= '"'

JSON 호환성을 위한 이스케이프된 ASCII 슬래시(x2F).

[53] ns-esc-slash ::= '/'

이스케이프된 ASCII 백슬래시(x5C).

[54] ns-esc-backslash ::= '\'

이스케이프된 Unicode 다음 줄(x85) 문자.

[55] ns-esc-next-line ::= 'N'

이스케이프된 Unicode 줄바꿈 없는 공백(xA0) 문자.

[56] ns-esc-non-breaking-space ::= '_'

이스케이프된 Unicode 줄 구분자(x2028) 문자.

[57] ns-esc-line-separator ::= 'L'

이스케이프된 Unicode 단락 구분자(x2029) 문자.

[58] ns-esc-paragraph-separator ::= 'P'

이스케이프된 8비트 Unicode 문자.

[59] ns-esc-8-bit ::=
  'x'
  ns-hex-digit{2}

이스케이프된 16비트 Unicode 문자.

[60] ns-esc-16-bit ::=
  'u'
  ns-hex-digit{4}

이스케이프된 32비트 Unicode 문자.

[61] ns-esc-32-bit ::=
  'U'
  ns-hex-digit{8}

임의의 이스케이프 문자:

[62] c-ns-esc-char ::=
  c-escape         # '\'
  (
      ns-esc-null
    | ns-esc-bell
    | ns-esc-backspace
    | ns-esc-horizontal-tab
    | ns-esc-line-feed
    | ns-esc-vertical-tab
    | ns-esc-form-feed
    | ns-esc-carriage-return
    | ns-esc-escape
    | ns-esc-space
    | ns-esc-double-quote
    | ns-esc-slash
    | ns-esc-backslash
    | ns-esc-next-line
    | ns-esc-non-breaking-space
    | ns-esc-line-separator
    | ns-esc-paragraph-separator
    | ns-esc-8-bit
    | ns-esc-16-bit
    | ns-esc-32-bit
  )

예제 5.13 이스케이프 문자

- "Fun with \\"
- "\" \a \b \e \f"
- "\n \r \t \v \0"
- "\  \_ \N \L \P \
  \x41 \u0041 \U00000041"

[ "Fun with \\",
  "\" \u0007 \b \u001b \f",
  "\n \r \t \u000b \u0000",
  "\u0020 \u00a0 \u0085 \u2028 \u2029 A A A" ]

범례:

예제 5.14 유효하지 않은 이스케이프 문자

Bad escapes:
  "\c
  \xq-"

ERROR:
- c is an invalid escaped character.
- q and - are invalid hex digits.

제6장. 구조 생성 규칙

6.1. 들여쓰기 공백

YAML 블록 스타일에서 구조는 들여쓰기로 결정됩니다. 일반적으로 들여쓰기는 줄의 시작에 있는 0개 이상의 스페이스 문자로 정의됩니다.

이식성을 유지하기 위해, 탭 문자는 들여쓰기에 사용해서는 안 됩니다. 서로 다른 시스템이 탭을 다르게 처리하기 때문입니다. 대부분의 현대 편집기는 탭 키를 누르면 적절한 수의 스페이스가 삽입되도록 설정할 수 있다는 점에 유의하십시오.

들여쓰기의 양은 프레젠테이션 세부 사항이며, 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다. 

[63]
s-indent(0) ::=
  <empty>

# When n≥0
s-indent(n+1) ::=
  s-space s-indent(n)

블록 스타일 구성은 해당 구성보다 덜 들여쓰기된 줄을 만나면 종료됩니다. 생성 규칙은 이를 표현하기 위해 “s-indent-less-than(n)” 및 “s-indent-less-or-equal(n)” 표기를 사용합니다.

[64]
s-indent-less-than(1) ::=
  <empty>

# When n≥1
s-indent-less-than(n+1) ::=
  s-space s-indent-less-than(n)
  | <empty>

[65]
s-indent-less-or-equal(0) ::=
  <empty>

# When n≥0
s-indent-less-or-equal(n+1) ::=
  s-space s-indent-less-or-equal(n)
  | <empty>

각 노드는 자신의 부모 노드보다 더 들여쓰기되어야 합니다. 모든 형제 노드는 정확히 같은 들여쓰기 수준을 사용해야 합니다. 그러나 각 형제 노드의 콘텐츠는 독립적으로 더 들여쓰기될 수 있습니다.

예제 6.1 들여쓰기 공백

··# Leading comment line spaces are
···# neither content nor indentation.
····
Not indented:
·By one space: |
····By four
······spaces
·Flow style: [    # Leading spaces
···By two,        # in flow style
··Also by two,    # are neither
··→Still by two   # content nor
····]             # indentation.

{ "Not indented": {
    "By one space": "By four\n  spaces\n",
    "Flow style": [
      "By two",
      "Also by two",
      "Still by two" ] } }

범례:

  • s-indent(n)
  • 콘텐츠
  • 콘텐츠도 들여쓰기도 아님

블록 컬렉션 항목을 나타내는 데 사용되는 “-”, “?” 및 “:” 문자는 사람들이 들여쓰기의 일부로 인식합니다. 이는 관련 생성 규칙에서 사례별로 처리됩니다.

예제 6.2 들여쓰기 표시자

?·a
:·-→b
··-··-→c
·····-·d

{ "a":
  [ "b",
    [ "c",
      "d" ] ] }

범례:

  • 전체 들여쓰기
  • s-indent(n)
  • 들여쓰기로서의 표시자

6.2. 분리 공백

들여쓰기와 스칼라 콘텐츠 밖에서, YAML은 한 줄 안의 토큰 사이 분리를 위해 공백 문자를 사용합니다. 이러한 공백에는 탭 문자가 안전하게 포함될 수 있다는 점에 유의하십시오.

분리 공백은 프레젠테이션 세부 사항이며 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다. 

[66] s-separate-in-line ::=
    s-white+
  | <start-of-line>

예제 6.3 분리 공백

-·foo:→·bar
- -·baz
  -→baz

[ { "foo": "bar" },
  [ "baz",
    "baz" ] ]

범례:

6.3. 줄 접두사

스칼라 콘텐츠 안에서 각 줄은 콘텐츠가 아닌 줄 접두사로 시작합니다. 이 접두사는 항상 들여쓰기를 포함합니다. 흐름 스칼라 스타일에서는 여기에 모든 선행 공백도 추가로 포함되며, 이는 탭 문자를 포함할 수 있습니다.

줄 접두사는 프레젠테이션 세부 사항이며 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다. 

[67]
s-line-prefix(n,BLOCK-OUT) ::= s-block-line-prefix(n)
s-line-prefix(n,BLOCK-IN)  ::= s-block-line-prefix(n)
s-line-prefix(n,FLOW-OUT)  ::= s-flow-line-prefix(n)
s-line-prefix(n,FLOW-IN)   ::= s-flow-line-prefix(n)

[68] s-block-line-prefix(n) ::=
  s-indent(n)

[69] s-flow-line-prefix(n) ::=
  s-indent(n)
  s-separate-in-line?

예제 6.4 줄 접두사

plain: text
··lines
quoted: "text
··→lines"
block: |
··text
···→lines

{ "plain": "text lines",
  "quoted": "text lines",
  "block": "text\n \tlines\n" }

범례:

6.4. 빈 줄

빈 줄은 콘텐츠가 아닌 접두사 뒤에 줄 바꿈이 오는 줄로 구성됩니다.

[70] l-empty(n,c) ::=
  (
      s-line-prefix(n,c)
    | s-indent-less-than(n)
  )
  b-as-line-feed

빈 줄의 의미는 그 빈 줄이 나타나는 스칼라 스타일에 따라 달라집니다. 이는 관련 생성 규칙에서 사례별로 처리됩니다.

예제 6.5 빈 줄

Folding:
  "Empty line
···→
  as a line feed"
Chomping: |
  Clipped empty lines
·

{ "Folding": "Empty line\nas a line feed",
  "Chomping": "Clipped empty lines\n" }

범례:

6.5. 줄 접기

줄 접기는 원래 긴 줄의 의미를 유지하면서 가독성을 위해 긴 줄을 나눌 수 있게 합니다. 줄바꿈 뒤에 빈 줄이 오면, 이는 잘립니다. 첫 번째 줄바꿈은 버려지고 나머지는 콘텐츠로 유지됩니다. 

[71] b-l-trimmed(n,c) ::=
  b-non-content
  l-empty(n,c)+

그렇지 않은 경우(다음 줄이 비어 있지 않은 경우), 줄바꿈은 단일 스페이스(x20)로 변환됩니다. 

[72] b-as-space ::=
  b-break

접힌 비-빈 줄은 위 두 줄바꿈 중 어느 것으로도 끝날 수 있습니다.

[73] b-l-folded(n,c) ::=
  b-l-trimmed(n,c) | b-as-space

예제 6.6 줄 접기

>-
  trimmed↓
··↓
·↓
↓
  as↓
  space

"trimmed\n\n\nas space"

범례:

위 규칙은 접힌 블록 스타일과 스칼라 흐름 스타일 모두에 공통됩니다. 접기는 다음 방식으로 이 경우들을 구분합니다.

블록 접기

접힌 블록 스타일에서 마지막 줄바꿈과 후행 빈 줄은 촘핑의 대상이며 결코 접히지 않습니다. 또한 선행 공백을 포함하는 텍스트 줄 주위의 줄바꿈에는 접기가 적용되지 않습니다. 이러한 더 많이 들여쓴 줄은 선행 공백만으로 구성될 수도 있다는 점에 유의하십시오.

블록 줄 접기 규칙의 결합 효과는 각 “단락”이 한 줄로 해석되고, 빈 줄은 줄바꿈으로 해석되며, 더 많이 들여쓴 줄의 형식이 보존된다는 것입니다.

예제 6.7 블록 접기

>
··foo·↓
·↓
··→·bar↓
↓
··baz↓

"foo \n\n\t bar\n\nbaz\n"

범례:

흐름 접기

흐름 스타일에서의 접기는 더 완화된 의미론을 제공합니다. 흐름 스타일은 일반적으로 구조를 전달하기 위해 들여쓰기가 아니라 명시적인 표시자에 의존합니다. 따라서 한 줄의 텍스트 앞이나 뒤에 오는 공백은 프레젠테이션 세부 사항이며, 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다. 이러한 공백이 모두 버려지면, 모든 줄바꿈은 예외 없이 접힙니다.

흐름 줄 접기 규칙의 결합 효과는 각 “단락”이 한 줄로 해석되고, 빈 줄은 줄바꿈으로 해석되며, 텍스트가 자유롭게 더 많이 들여쓰기되어도 콘텐츠 정보에 영향을 주지 않는다는 것입니다. 

[74] s-flow-folded(n) ::=
  s-separate-in-line?
  b-l-folded(n,FLOW-IN)
  s-flow-line-prefix(n)

예제 6.8 흐름 접기

"↓
··foo·↓
·↓
··→·bar↓
↓
··baz↓ "

" foo\nbar\nbaz "

범례:

6.6. 주석

명시적 주석은 “#” 표시자로 표시됩니다. 주석은 프레젠테이션 세부 사항이며, 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다.

주석은 공백 문자로 다른 토큰과 분리되어야 합니다.

참고: JSON 호환성을 보장하기 위해, YAML 프로세서는 입력 스트림의 마지막 주석 줄바꿈이 생략되는 것을 허용해야 합니다. 그러나 이는 많은 도구를 혼란스럽게 하므로, YAML 프로세서는 출력 시 명시적인 줄바꿈으로 스트림을 종료해야 합니다. 

[75] c-nb-comment-text ::=
  c-comment    # '#'
  nb-char*

[76] b-comment ::=
    b-non-content
  | <end-of-input>

[77] s-b-comment ::=
  (
    s-separate-in-line
    c-nb-comment-text?
  )?
  b-comment

예제 6.9 분리된 주석

key:····# Comment↓
  valueeof

{ "key": "value" }

범례:

스칼라 콘텐츠 밖에서 주석은 자체 줄에 나타날 수 있으며, 들여쓰기 수준과 무관합니다. 스칼라 콘텐츠 밖에서는 공백 문자만 포함하는 줄이 주석 줄로 간주된다는 점에 유의하십시오. 

[78] l-comment ::=
  s-separate-in-line
  c-nb-comment-text?
  b-comment

예제 6.10 주석 줄

··# Comment↓
···↓
↓

# This stream contains no
# documents, only comments.

범례:

대부분의 경우 한 줄이 주석으로 끝날 수 있으면, YAML은 그 뒤에 추가 주석 줄이 이어지는 것도 허용합니다. 유일한 예외는 블록 스칼라 헤더를 끝내는 주석입니다.

[79] s-l-comments ::=
  (
      s-b-comment
    | <start-of-line>
  )
  l-comment*

예제 6.11 여러 줄 주석

key:····# Comment↓
········# lines↓
  value↓
↓

{ "key": "value" }

범례:

6.7. 분리 줄

암시적 키는 한 줄로 제한됩니다. 그 밖의 모든 경우에 YAML은 여러 줄(비어 있을 수도 있는) 주석으로 토큰을 분리하는 것을 허용합니다.

여러 줄 주석 분리 뒤에 오는 구조는 적절하게 들여쓰기되어야 한다는 점에 유의하십시오. 하지만 분리 주석 줄 자체에는 그런 제한이 없습니다. 

[80]
s-separate(n,BLOCK-OUT) ::= s-separate-lines(n)
s-separate(n,BLOCK-IN)  ::= s-separate-lines(n)
s-separate(n,FLOW-OUT)  ::= s-separate-lines(n)
s-separate(n,FLOW-IN)   ::= s-separate-lines(n)
s-separate(n,BLOCK-KEY) ::= s-separate-in-line
s-separate(n,FLOW-KEY)  ::= s-separate-in-line

[81] s-separate-lines(n) ::=
    (
      s-l-comments
      s-flow-line-prefix(n)
    )
  | s-separate-in-line

예제 6.12 분리 공백

{·first:·Sammy,·last:·Sosa·}:↓
# Statistics:
··hr:··# Home runs
·····65
··avg:·# Average
···0.278

{ { "first": "Sammy",
    "last": "Sosa" }: {
    "hr": 65,
    "avg": 0.278 } }

범례:

6.8. 지시문

지시문은 YAML 프로세서에 대한 명령입니다. 이 명세는 “YAML”과 “TAG”라는 두 지시문을 정의하고, 다른 모든 지시문은 향후 사용을 위해 예약합니다. 비공개 지시문을 정의하는 방법은 없습니다. 이는 의도된 것입니다.

지시문은 프레젠테이션 세부 사항이며, 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다. 

[82] l-directive ::=
  c-directive            # '%'
  (
      ns-yaml-directive
    | ns-tag-directive
    | ns-reserved-directive
  )
  s-l-comments

각 지시문은 “%” 표시자로 시작하고 지시문 이름과 매개변수 목록이 뒤따르는 별도의 비-들여쓰기 줄에 지정됩니다. 이러한 매개변수의 의미는 특정 지시문에 따라 달라집니다. YAML 프로세서는 알 수 없는 지시문을 적절한 경고와 함께 무시해야 합니다.

[83] ns-reserved-directive ::=
  ns-directive-name
  (
    s-separate-in-line
    ns-directive-parameter
  )*

[84] ns-directive-name ::=
  ns-char+

[85] ns-directive-parameter ::=
  ns-char+

예제 6.13 예약된 지시문

%FOO  bar baz # Should be ignored
               # with a warning.
--- "foo"

"foo"

범례:

6.8.1. “YAML” 지시문

“YAML” 지시문은 문서가 준수하는 YAML 버전을 지정합니다. 이 명세는 YAML 1.1 처리에 대한 권고를 포함하여 버전 “1.2”를 정의합니다.

버전 1.2 YAML 프로세서는 명시적 “%YAML 1.2” 지시문이 있는 문서와 “YAML” 지시문이 없는 문서를 모두 허용해야 합니다. 그러한 문서는 1.2 버전 명세를 준수한다고 가정됩니다. 더 높은 부 버전(예: “%YAML 1.3”)을 지정하는 “YAML” 지시문이 있는 문서는 적절한 경고와 함께 처리해야 합니다. 더 높은 주 버전(예: “%YAML 2.0”)을 지정하는 “YAML” 지시문이 있는 문서는 적절한 오류 메시지와 함께 거부해야 합니다.

버전 1.2 YAML 프로세서는 명시적 “%YAML 1.1” 지시문이 있는 문서도 허용해야 합니다. 버전 1.2는 JSON 호환성을 보장할 목적으로 정의된, 대부분 버전 1.1의 상위 집합이라는 점에 유의하십시오. 따라서 버전 1.2 프로세서는 버전 1.1 문서를 버전 1.2인 것처럼 처리하고, 비호환 지점(비-ASCII 줄바꿈 처리, 위에서 설명됨)에 대해 경고를 제공해야 합니다. 

[86] ns-yaml-directive ::=
  "YAML"
  s-separate-in-line
  ns-yaml-version

[87] ns-yaml-version ::=
  ns-dec-digit+
  '.'
  ns-dec-digit+

예제 6.14 “YAML” 지시문

%YAML 1.3 # Attempt parsing
           # with a warning
---
"foo"

"foo"

범례:

같은 문서에 “YAML” 지시문을 둘 이상 지정하는 것은, 두 출현이 같은 버전 번호를 제공하더라도 오류입니다.

예제 6.15 유효하지 않은 반복 YAML 지시문

%YAML 1.2
%YAML 1.1
foo

ERROR:
The YAML directive must only be
given at most once per document.

6.8.2. “TAG” 지시문

“TAG” 지시문은 노드 태그를 지정하기 위한 태그 축약 표기법을 설정합니다. 각 “TAG” 지시문은 핸들을 접두사와 연결합니다. 이를 통해 간결하고 읽기 쉬운 태그 표기법을 사용할 수 있습니다. 

[88] ns-tag-directive ::=
  "TAG"
  s-separate-in-line
  c-tag-handle
  s-separate-in-line
  ns-tag-prefix

예제 6.16 “TAG” 지시문

%TAG !yaml! tag:yaml.org,2002:
---
!yaml!str "foo"

"foo"

범례:

같은 문서에서 같은 핸들에 대해 “TAG” 지시문을 둘 이상 지정하는 것은, 두 출현이 같은 접두사를 제공하더라도 오류입니다.

예제 6.17 유효하지 않은 반복 TAG 지시문

%TAG ! !foo
%TAG ! !foo
bar

ERROR:
The TAG directive must only
be given at most once per
handle in the same document.

6.8.2.1. 태그 핸들

태그 핸들은 영향을 받는 태그 축약의 접두사와 정확히 일치합니다. 태그 핸들에는 세 가지 변형이 있습니다.

[89] c-tag-handle ::=
    c-named-tag-handle
  | c-secondary-tag-handle
  | c-primary-tag-handle
기본 핸들

기본 태그 핸들은 단일 “!” 문자입니다. 이를 통해 단일 “기본” 네임스페이스에 대해 가능한 가장 간결한 표기법을 사용할 수 있습니다. 기본적으로 이 핸들과 연결된 접두사는 “!”입니다. 따라서 기본적으로 이 핸들을 사용하는 축약은 로컬 태그로 해석됩니다.

명시적인 “TAG” 지시문을 제공하여 이 핸들에 다른 접두사를 연결함으로써 기본 동작을 재정의할 수 있습니다. 이는 단일 “TAG” 지시문을 간단히 추가하는 것만으로 로컬 태그 사용에서 전역 태그 사용으로 원활하게 이전할 수 있게 합니다. 

[90] c-primary-tag-handle ::= '!'

예제 6.18 기본 태그 핸들

# Private
!foo "bar"
...
# Global
%TAG ! tag:example.com,2000:app/
---
!foo "bar"

!<!foo> "bar"
---
!<tag:example.com,2000:app/foo> "bar"

범례:

보조 핸들

보조 태그 핸들은 “!!”로 작성됩니다. 이를 통해 단일 “보조” 네임스페이스에 대해 간결한 표기법을 사용할 수 있습니다. 기본적으로 이 핸들과 연결된 접두사는 “tag:yaml.org,2002:”입니다.

명시적인 “TAG” 지시문을 제공하여 이 핸들에 다른 접두사를 연결함으로써 이 기본 동작을 재정의할 수 있습니다.

[91] c-secondary-tag-handle ::= "!!"

예제 6.19 보조 태그 핸들

%TAG !! tag:example.com,2000:app/
---
!!int 1 - 3 # Interval, not integer

!<tag:example.com,2000:app/int> "1 - 3"

범례:

이름 있는 핸들

이름 있는 태그 핸들은 비어 있지 않은 이름을 “!” 문자로 둘러쌉니다. 명시적인 “TAG” 지시문이 어떤 접두사를 연결하지 않았다면, 핸들 이름은 태그 축약에서 사용해서는 안 됩니다.

핸들의 이름은 프레젠테이션 세부 사항이며, 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다. 특히 YAML 프로세서는 파싱이 완료된 뒤 핸들 이름을 보존할 필요가 없습니다. 

[92] c-named-tag-handle ::=
  c-tag            # '!'
  ns-word-char+
  c-tag            # '!'

예제 6.20 태그 핸들

%TAG !e! tag:example.com,2000:app/
---
!e!foo "bar"

!<tag:example.com,2000:app/foo> "bar"

범례:

6.8.2.2. 태그 접두사

태그 접두사에는 두 가지 변형이 있습니다.

[93] ns-tag-prefix ::=
  c-ns-local-tag-prefix | ns-global-tag-prefix
로컬 태그 접두사

접두사가 “!” 문자로 시작하면, 해당 핸들을 사용하는 축약은 로컬 태그로 확장됩니다. 이러한 태그는 의도적으로 유효한 URI가 아니며, 그 의미는 애플리케이션에 특화되어 있다는 점에 유의하십시오. 특히 같은 스트림 안의 두 문서는 같은 로컬 태그에 서로 다른 의미를 부여할 수 있습니다. 

[94] c-ns-local-tag-prefix ::=
  c-tag           # '!'
  ns-uri-char*

예제 6.21 로컬 태그 접두사

%TAG !m! !my-
--- # Bulb here
!m!light fluorescent
...
%TAG !m! !my-
--- # Color here
!m!light green

!<!my-light> "fluorescent"
---
!<!my-light> "green"

범례:

전역 태그 접두사

접두사가 “!”가 아닌 문자로 시작하면, 이는 유효한 URI 접두사여야 하며, 적어도 스킴을 포함해야 합니다. 연결된 핸들을 사용하는 축약은 전역적으로 고유한 URI 태그로 확장되며, 그 의미는 애플리케이션 전반에서 일관됩니다. 특히 모든 스트림의 모든 문서는 같은 전역 태그에 같은 의미를 부여해야 합니다. 

[95] ns-global-tag-prefix ::=
  ns-tag-char
  ns-uri-char*

예제 6.22 전역 태그 접두사

%TAG !e! tag:example.com,2000:app/
---
- !e!foo "bar"

- !<tag:example.com,2000:app/foo> "bar"

범례:

6.9. 노드 속성

각 노드는 자신의 콘텐츠 외에도 두 개의 선택적 속성, 즉 앵커와 태그를 가질 수 있습니다. 노드 속성은 노드의 콘텐츠 앞에 임의의 순서로 지정할 수 있습니다. 둘 중 하나 또는 둘 다 생략할 수 있습니다.

[96] c-ns-properties(n,c) ::=
    (
      c-ns-tag-property
      (
        s-separate(n,c)
        c-ns-anchor-property
      )?
    )
  | (
      c-ns-anchor-property
      (
        s-separate(n,c)
        c-ns-tag-property
      )?
    )

예제 6.23 노드 속성

!!str &a1 "foo":
  !!str bar
&a2 baz : *a1

{ &B1 "foo": "bar",
  "baz": *B1 }

범례:

6.9.1. 노드 태그

태그 속성은 노드가 제시하는 네이티브 데이터 구조의 타입을 식별합니다. 태그는 “!” 표시자로 나타냅니다. 

[97] c-ns-tag-property ::=
    c-verbatim-tag
  | c-ns-shorthand-tag
  | c-non-specific-tag
축자 태그

태그는 “<” 및 “>” 문자로 둘러싸 축자적으로 작성할 수 있습니다. 이 경우 YAML 프로세서는 축자 태그를 그대로 애플리케이션에 전달해야 합니다. 특히 축자 태그는 태그 해석의 대상이 아닙니다. 축자 태그는 “!”(로컬 태그)로 시작하거나 유효한 URI(전역 태그)여야 합니다. 

[98] c-verbatim-tag ::=
  "!<"
  ns-uri-char+
  '>'

예제 6.24 축자 태그

!<tag:yaml.org,2002:str> foo :
  !<!bar> baz

{ "foo": !<!bar> "baz" }

범례:

예제 6.25 유효하지 않은 축자 태그

- !<!> foo
- !<$:?> bar

ERROR:
- Verbatim tags aren't resolved,
  so ! is invalid.
- The $:? tag is neither a global
  URI tag nor a local tag starting
  with '!'.
태그 축약

태그 축약은 유효한 태그 핸들 뒤에 비어 있지 않은 접미사가 오는 것으로 구성됩니다. 태그 핸들은 기본값에 의해 또는 “TAG” 지시문을 사용하여 접두사와 연결되어 있어야 합니다. 결과로 파싱된 태그는 접두사와 접미사의 연결이며, “!”(로컬 태그)로 시작하거나 유효한 URI(전역 태그)여야 합니다.

태그 핸들의 선택은 프레젠테이션 세부 사항이며, 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다. 특히 태그 핸들은 파싱이 완료되면 버려질 수 있습니다.

접미사는 “!” 문자를 포함해서는 안 됩니다. 이는 태그 축약이 이름 있는 태그 핸들을 가진 것으로 해석되게 할 수 있습니다. 또한 접미사는 “[”, “]”, “{”, “}” 및 “,” 문자를 포함해서는 안 됩니다. 이러한 문자는 흐름 컬렉션 구조와 모호성을 일으킬 수 있습니다. 접미사가 위의 제한된 문자 중 하나를 지정해야 하는 경우, “%” 문자를 사용해 이스케이프해야 합니다. 이 동작은 URI 문자 이스케이프 규칙(특히 URI RFC의 2.3절)과 일관됩니다. 

[99] c-ns-shorthand-tag ::=
  c-tag-handle
  ns-tag-char+

예제 6.26 태그 축약

%TAG !e! tag:example.com,2000:app/
---
- !local foo
- !!str bar
- !e!tag%21 baz

[ !<!local> "foo",
  !<tag:yaml.org,2002:str> "bar",
  !<tag:example.com,2000:app/tag!> "baz" ]

범례:

예제 6.27 유효하지 않은 태그 축약

%TAG !e! tag:example,2000:app/
---
- !e! foo
- !h!bar baz

ERROR:
- The !e! handle has no suffix.
- The !h! handle wasn't declared.
비특정 태그

노드에 태그 속성이 없으면, 특정 태그로 해석되어야 하는 비특정 태그가 할당됩니다. 이 비특정 태그는 비-일반 스칼라에는 “!”이고, 그 밖의 모든 노드에는 “?”입니다. 이는 노드 스타일이 콘텐츠 정보에 영향을 미치는 유일한 경우입니다.

태그 속성을 명시적으로 “!” 비특정 태그로 설정할 수 있습니다. 관례상 이 “태그 해석을 비활성화”하여, 노드가 자신의 종류에 따라 “tag:yaml.org,2002:seq”, “tag:yaml.org,2002:map” 또는 “tag:yaml.org,2002:str”로 해석되도록 강제합니다.

“?” 비특정 태그를 명시적으로 지정하는 방법은 없습니다. 이는 의도된 것입니다.

[100] c-non-specific-tag ::= '!'

예제 6.28 비특정 태그

# Assuming conventional resolution:
- "12"
- 12
- ! 12

[ "12",
  12,
  "12" ]

범례:

6.9.2. 노드 앵커

앵커는 “&” 표시자로 나타냅니다. 이는 향후 참조를 위해 노드를 표시합니다. 그러면 별칭 노드를 사용해 앵커가 지정된 노드의 추가 포함을 나타낼 수 있습니다. 앵커가 지정된 노드는 어떤 별칭 노드에서도 참조될 필요가 없습니다. 특히 모든 노드에 앵커를 지정하는 것도 유효합니다.

[101] c-ns-anchor-property ::=
  c-anchor          # '&'
  ns-anchor-name

직렬화 세부 사항으로서 앵커 이름은 직렬화 트리에 보존된다는 점에 유의하십시오. 그러나 이는 표현 그래프에는 반영되지 않으며 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다. 특히 YAML 프로세서는 표현이 구성된 뒤에는 앵커 이름을 보존할 필요가 없습니다.

앵커 이름은 “[”, “]”, “{”, “}” 및 “,” 문자를 포함해서는 안 됩니다. 이러한 문자는 흐름 컬렉션 구조와 모호성을 일으킬 수 있습니다.

[102] ns-anchor-char ::=
    ns-char - c-flow-indicator

[103] ns-anchor-name ::=
  ns-anchor-char+

예제 6.29 노드 앵커

First occurrence: &anchor Value
Second occurrence: *anchor

{ "First occurrence": &A "Value",
  "Second occurrence": *A }

범례:

제7장. 흐름 스타일 생성 규칙

YAML의 흐름 스타일은 가독성을 위해 긴 콘텐츠 줄을 접고, 네이티브 데이터 구조의 생성을 제어하기 위해 노드에 태그를 붙이며, 생성된 객체 인스턴스를 재사용하기 위해 앵커와 별칭을 사용하는, JSON의 자연스러운 확장으로 생각할 수 있습니다.

7.1. 별칭 노드

이전에 직렬화된 노드가 이후에 다시 나타나면 별칭 노드로 제시됩니다. 이후 출현을 별칭 노드로 제시할 수 있도록, 노드의 첫 번째 출현은 반드시 앵커로 표시되어야 합니다.

별칭 노드는 “*” 표시자로 나타냅니다. 별칭은 같은 앵커를 가진 가장 최근의 앞선 노드를 참조합니다. 별칭 노드가 문서 안에서 이전에 나타나지 않은 앵커를 사용하는 것은 오류입니다. 어떤 별칭 노드에서도 사용하지 않는 앵커를 지정하는 것은 오류가 아닙니다.

별칭 노드는 속성이나 콘텐츠를 지정해서는 안 됩니다. 이는 이미 노드의 첫 번째 출현에서 지정되었기 때문입니다.

[104] c-ns-alias-node ::=
  c-alias           # '*'
  ns-anchor-name

예제 7.1 별칭 노드

First occurrence: &anchor Foo
Second occurrence: *anchor
Override anchor: &anchor Bar
Reuse anchor: *anchor

{ "First occurrence": &A "Foo",
  "Override anchor": &B "Bar",
  "Second occurrence": *A,
  "Reuse anchor": *B }

범례:

7.2. 빈 노드

YAML은 많은 경우 노드 콘텐츠가 생략되는 것을 허용합니다. 빈 콘텐츠를 가진 노드는 빈 값을 가진 일반 스칼라인 것처럼 해석됩니다. 이러한 노드는 흔히 “null” 값으로 해석됩니다. 

[105] e-scalar ::= ""

예제에서 빈 스칼라는 명확성을 위해 때때로 “°” 글리프로 표시됩니다. 이 글리프는 실제 문자가 아니라 문자 스트림 안의 위치에 대응한다는 점에 유의하십시오.

예제 7.2 빈 콘텐츠

{
  foo : !!str°,
  !!str° : bar,
}

{ "foo": "",
  "": "bar" }

범례:

노드의 속성과 노드 콘텐츠는 모두 선택 사항입니다. 이는 완전히 빈 노드를 허용합니다. 완전히 빈 노드는 그 존재에 대한 어떤 명시적 표시 뒤에 올 때만 유효합니다.

[106] e-node ::=
  e-scalar    # ""

예제 7.3 완전히 빈 흐름 노드

{
  ? foo :°,
  °: bar,
}

{ "foo": null,
  null : "bar" }

범례:

7.3. 흐름 스칼라 스타일

YAML은 세 가지 흐름 스칼라 스타일을 제공합니다. 큰따옴표, 작은따옴표, 그리고 일반(따옴표 없음) 스타일입니다. 각각은 가독성과 표현력 사이에서 서로 다른 절충을 제공합니다.

스칼라 스타일은 프레젠테이션 세부 사항이며, 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다. 단, 일반 스칼라가 태그 해석을 위해 구별되는 경우는 예외입니다.

7.3.1. 큰따옴표 스타일

큰따옴표 스타일은 “"” 표시자로 둘러싸 지정됩니다. 이는 “\” 이스케이프 시퀀스를 사용하여 임의의 문자열을 표현할 수 있는 유일한 스타일입니다. 그 대가로 “\” 및 “"” 문자를 이스케이프해야 합니다. 

[107] nb-double-char ::=
    c-ns-esc-char
  | (
        nb-json
      - c-escape          # '\'
      - c-double-quote    # '"'
    )

[108] ns-double-char ::=
  nb-double-char - s-white

큰따옴표 스칼라는 암시적 키 안에 포함될 때 한 줄로 제한됩니다. 

[109] c-double-quoted(n,c) ::=
  c-double-quote         # '"'
  nb-double-text(n,c)
  c-double-quote         # '"'

[110]
nb-double-text(n,FLOW-OUT)  ::= nb-double-multi-line(n)
nb-double-text(n,FLOW-IN)   ::= nb-double-multi-line(n)
nb-double-text(n,BLOCK-KEY) ::= nb-double-one-line
nb-double-text(n,FLOW-KEY)  ::= nb-double-one-line

[111] nb-double-one-line ::=
  nb-double-char*

예제 7.4 큰따옴표 암시적 키

"implicit block key" : [
  "implicit flow key" : value,
 ]

{ "implicit block key":
  [ { "implicit flow key": "value" } ] }

범례:

여러 줄 큰따옴표 스칼라에서 줄바꿈은 흐름 줄 접기의 대상이 되며, 후행 공백 문자는 버려집니다. 줄바꿈 문자를 이스케이프하는 것도 가능합니다. 이 경우 이스케이프된 줄바꿈은 콘텐츠에서 제외되고, 이스케이프된 줄바꿈 앞의 후행 공백 문자는 보존됩니다. 공백 문자를 이스케이프할 수 있는 기능과 결합하면, 큰따옴표 줄을 임의의 위치에서 나눌 수 있습니다. 

[112] s-double-escaped(n) ::=
  s-white*
  c-escape         # '\'
  b-non-content
  l-empty(n,FLOW-IN)*
  s-flow-line-prefix(n)

[113] s-double-break(n) ::=
    s-double-escaped(n)
  | s-flow-folded(n)

예제 7.5 큰따옴표 줄바꿈

"folded·↓
to a space,→↓
·↓
to a line feed, or·→\↓
·\·→non-content"

"folded to a space,\nto a line feed, or \t \tnon-content"

범례:

각 줄의 모든 선행 및 후행 공백 문자는 콘텐츠에서 제외됩니다. 따라서 각 이어지는 줄에는 적어도 하나의 비-스페이스 문자가 있어야 합니다. 빈 줄이 있다면 줄 접기의 일부로 소비됩니다. 

[114] nb-ns-double-in-line ::=
  (
    s-white*
    ns-double-char
  )*

[115] s-double-next-line(n) ::=
  s-double-break(n)
  (
    ns-double-char nb-ns-double-in-line
    (
        s-double-next-line(n)
      | s-white*
    )
  )?

[116] nb-double-multi-line(n) ::=
  nb-ns-double-in-line
  (
      s-double-next-line(n)
    | s-white*
  )

예제 7.6 큰따옴표 줄

"·1st non-empty↓
↓
·2nd non-empty·
→3rd non-empty·"

" 1st non-empty\n2nd non-empty 3rd non-empty "

범례:

7.3.2. 작은따옴표 스타일

작은따옴표 스타일은 “'” 표시자로 둘러싸 지정됩니다. 따라서 작은따옴표 스칼라 안에서는 이러한 문자를 반복해서 써야 합니다. 이것이 작은따옴표 스칼라에서 수행되는 유일한 이스케이프 형식입니다. 특히 “\” 및 “"” 문자는 자유롭게 사용할 수 있습니다. 이로 인해 작은따옴표 스칼라는 인쇄 가능 문자로 제한됩니다. 또한 긴 작은따옴표 줄은 스페이스 문자가 비-스페이스로 둘러싸인 위치에서만 나눌 수 있습니다. 

[117] c-quoted-quote ::= "''"

[118] nb-single-char ::=
    c-quoted-quote
  | (
        nb-json
      - c-single-quote    # "'"
    )

[119] ns-single-char ::=
  nb-single-char - s-white

예제 7.7 작은따옴표 문자

'here''s to "quotes"'

"here's to \"quotes\""

범례:

작은따옴표 스칼라는 암시적 키 안에 포함될 때 한 줄로 제한됩니다. 

[120] c-single-quoted(n,c) ::=
  c-single-quote    # "'"
  nb-single-text(n,c)
  c-single-quote    # "'"

[121]
nb-single-text(FLOW-OUT)  ::= nb-single-multi-line(n)
nb-single-text(FLOW-IN)   ::= nb-single-multi-line(n)
nb-single-text(BLOCK-KEY) ::= nb-single-one-line
nb-single-text(FLOW-KEY)  ::= nb-single-one-line

[122] nb-single-one-line ::=
  nb-single-char*

예제 7.8 작은따옴표 암시적 키

'implicit block key' : [
  'implicit flow key' : value,
 ]

{ "implicit block key":
  [ { "implicit flow key": "value" } ] }

범례:

모든 선행 및 후행 공백 문자는 콘텐츠에서 제외됩니다. 따라서 각 이어지는 줄에는 적어도 하나의 비-스페이스 문자가 있어야 합니다. 빈 줄이 있다면 줄 접기의 일부로 소비됩니다. 

[123] nb-ns-single-in-line ::=
  (
    s-white*
    ns-single-char
  )*

[124] s-single-next-line(n) ::=
  s-flow-folded(n)
  (
    ns-single-char
    nb-ns-single-in-line
    (
        s-single-next-line(n)
      | s-white*
    )
  )?

[125] nb-single-multi-line(n) ::=
  nb-ns-single-in-line
  (
      s-single-next-line(n)
    | s-white*
  )

예제 7.9 작은따옴표 줄

'·1st non-empty↓
↓
·2nd non-empty·
→3rd non-empty·'

" 1st non-empty\n2nd non-empty 3rd non-empty "

범례:

7.3.3. 일반 스타일

일반(따옴표 없음) 스타일은 식별용 표시자가 없고 어떤 이스케이프 형식도 제공하지 않습니다. 따라서 가장 읽기 쉽지만, 가장 제한적이고 가장 컨텍스트에 민감한 스타일입니다. 제한된 문자 집합 외에도, 일반 스칼라는 비어 있거나 선행 또는 후행 공백 문자를 포함해서는 안 됩니다. 긴 일반 줄은 스페이스 문자가 비-스페이스로 둘러싸인 위치에서만 나눌 수 있습니다.

일반 스칼라는 대부분의 표시자로 시작해서는 안 됩니다. 이는 다른 YAML 구성과 모호성을 일으킬 수 있기 때문입니다. 그러나 “:”, “?” 및 “-” 표시자는 비-스페이스 “안전” 문자가 뒤따르는 경우 첫 문자로 사용할 수 있습니다. 이 경우 모호성이 생기지 않기 때문입니다.

[126] ns-plain-first(c) ::=
    (
        ns-char
      - c-indicator
    )
  | (
      (
          c-mapping-key       # '?'
        | c-mapping-value     # ':'
        | c-sequence-entry    # '-'
      )
      [ lookahead = ns-plain-safe(c) ]
    )

일반 스칼라는 “: ” 및 “ #” 문자 조합을 절대 포함해서는 안 됩니다. 이러한 조합은 매핑 키/값 쌍 및 주석과 모호성을 일으킬 수 있습니다. 또한 흐름 컬렉션 내부에서, 또는 암시적 키로 사용될 때, 일반 스칼라는 “[”, “]”, “{”, “}” 및 “,” 문자를 포함해서는 안 됩니다. 이러한 문자는 흐름 컬렉션 구조와 모호성을 일으킬 수 있습니다. 

[127]
ns-plain-safe(FLOW-OUT)  ::= ns-plain-safe-out
ns-plain-safe(FLOW-IN)   ::= ns-plain-safe-in
ns-plain-safe(BLOCK-KEY) ::= ns-plain-safe-out
ns-plain-safe(FLOW-KEY)  ::= ns-plain-safe-in

[128] ns-plain-safe-out ::=
  ns-char

[129] ns-plain-safe-in ::=
  ns-char - c-flow-indicator

[130] ns-plain-char(c) ::=
    (
        ns-plain-safe(c)
      - c-mapping-value    # ':'
      - c-comment          # '#'
    )
  | (
      [ lookbehind = ns-char ]
      c-comment          # '#'
    )
  | (
      c-mapping-value    # ':'
      [ lookahead = ns-plain-safe(c) ]
    )

예제 7.10 일반 문자

# Outside flow collection:
- ::vector
- ": - ()"
- Up, up, and away!
- -123
- https://example.com/foo#bar
# Inside flow collection:
- [ ::vector,
  ": - ()",
  "Up, up and away!",
  -123,
  https://example.com/foo#bar ]

[ "::vector",
  ": - ()",
  "Up, up, and away!",
  -123,
  "http://example.com/foo#bar",
  [ "::vector",
    ": - ()",
    "Up, up, and away!",
    -123,
    "http://example.com/foo#bar" ] ]

범례:

일반 스칼라는 암시적 키 안에 포함될 때 추가로 한 줄로 제한됩니다. 

[131]
ns-plain(n,FLOW-OUT)  ::= ns-plain-multi-line(n,FLOW-OUT)
ns-plain(n,FLOW-IN)   ::= ns-plain-multi-line(n,FLOW-IN)
ns-plain(n,BLOCK-KEY) ::= ns-plain-one-line(BLOCK-KEY)
ns-plain(n,FLOW-KEY)  ::= ns-plain-one-line(FLOW-KEY)

[132] nb-ns-plain-in-line(c) ::=
  (
    s-white*
    ns-plain-char(c)
  )*

[133] ns-plain-one-line(c) ::=
  ns-plain-first(c)
  nb-ns-plain-in-line(c)

예제 7.11 일반 암시적 키

implicit block key : [
  implicit flow key : value,
 ]

{ "implicit block key":
  [ { "implicit flow key": "value" } ] }

범례:

모든 선행 및 후행 공백 문자는 콘텐츠에서 제외됩니다. 따라서 각 이어지는 줄에는 적어도 하나의 비-스페이스 문자가 있어야 합니다. 빈 줄이 있다면 줄 접기의 일부로 소비됩니다. 

[134] s-ns-plain-next-line(n,c) ::=
  s-flow-folded(n)
  ns-plain-char(c)
  nb-ns-plain-in-line(c)

[135] ns-plain-multi-line(n,c) ::=
  ns-plain-one-line(c)
  s-ns-plain-next-line(n,c)*

예제 7.12 일반 줄

1st non-empty↓
↓
·2nd non-empty·
→3rd non-empty

"1st non-empty\n2nd non-empty 3rd non-empty"

범례:

7.4. 흐름 컬렉션 스타일

흐름 컬렉션은 블록 컬렉션([FLOW-OUT 컨텍스트]) 안에 중첩되거나, 다른 흐름 컬렉션([FLOW-IN 컨텍스트]) 안에 중첩되거나, 암시적 키의 일부 ([FLOW-KEY 컨텍스트] 또는 [BLOCK-KEY 컨텍스트])가 될 수 있습니다. 흐름 컬렉션 항목은 “,” 표시자로 종료됩니다. 마지막 “,”는 생략할 수 있습니다. 흐름 컬렉션 항목은 결코 완전히 비어 있을 수 없으므로 이는 모호성을 일으키지 않습니다. 

[136]
in-flow(n,FLOW-OUT)  ::= ns-s-flow-seq-entries(n,FLOW-IN)
in-flow(n,FLOW-IN)   ::= ns-s-flow-seq-entries(n,FLOW-IN)
in-flow(n,BLOCK-KEY) ::= ns-s-flow-seq-entries(n,FLOW-KEY)
in-flow(n,FLOW-KEY)  ::= ns-s-flow-seq-entries(n,FLOW-KEY)

7.4.1. 흐름 시퀀스

흐름 시퀀스 콘텐츠는 “[” 및 “]” 문자로 둘러싸 표시됩니다.

[137] c-flow-sequence(n,c) ::=
  c-sequence-start    # '['
  s-separate(n,c)?
  in-flow(n,c)?
  c-sequence-end      # ']'

시퀀스 항목은 “,” 문자로 분리됩니다.

[138] ns-s-flow-seq-entries(n,c) ::=
  ns-flow-seq-entry(n,c)
  s-separate(n,c)?
  (
    c-collect-entry     # ','
    s-separate(n,c)?
    ns-s-flow-seq-entries(n,c)?
  )?

예제 7.13 흐름 시퀀스

- [ one, two, ]
- [three ,four]

[ [ "one",
    "two" ],
  [ "three",
    "four" ] ]

범례:

어떤 흐름 노드도 흐름 시퀀스 항목으로 사용할 수 있습니다. 또한 YAML은 흐름 시퀀스 항목이 단일 키/값 쌍을 가진 매핑인 경우를 위한 간결한 표기법을 제공합니다. 

[139] ns-flow-seq-entry(n,c) ::=
  ns-flow-pair(n,c) | ns-flow-node(n,c)

예제 7.14 흐름 시퀀스 항목

[
"double
 quoted", 'single
           quoted',
plain
 text, [ nested ],
single: pair,
]

[ "double quoted",
  "single quoted",
  "plain text",
  [ "nested" ],
  { "single": "pair" } ]

범례:

7.4.2. 흐름 매핑

흐름 매핑은 “{” 및 “}” 문자로 둘러싸 표시됩니다.

[140] c-flow-mapping(n,c) ::=
  c-mapping-start       # '{'
  s-separate(n,c)?
  ns-s-flow-map-entries(n,in-flow(c))?
  c-mapping-end         # '}'

매핑 항목은 “,” 문자로 분리됩니다.

[141] ns-s-flow-map-entries(n,c) ::=
  ns-flow-map-entry(n,c)
  s-separate(n,c)?
  (
    c-collect-entry     # ','
    s-separate(n,c)?
    ns-s-flow-map-entries(n,c)?
  )?

예제 7.15 흐름 매핑

- { one : two , three: four , }
- {five: six,seven : eight}

[ { "one": "two",
    "three": "four" },
  { "five": "six",
    "seven": "eight" } ]

범례:

선택적인 “?” 매핑 키 표시자가 지정되면, 항목의 나머지 부분은 완전히 비어 있을 수 있습니다.

[142] ns-flow-map-entry(n,c) ::=
    (
      c-mapping-key    # '?' (not followed by non-ws char)
      s-separate(n,c)
      ns-flow-map-explicit-entry(n,c)
    )
  | ns-flow-map-implicit-entry(n,c)

[143] ns-flow-map-explicit-entry(n,c) ::=
    ns-flow-map-implicit-entry(n,c)
  | (
      e-node    # ""
      e-node    # ""
    )

예제 7.16 흐름 매핑 항목

{
? explicit: entry,
implicit: entry,
?°°
}

{ "explicit": "entry",
  "implicit": "entry",
  null: null }

범례:

일반적으로 YAML은 “:” 매핑 값 표시자가 값과 공백으로 분리되어야 한다고 요구합니다. 이 제한의 장점은 “:” 문자가 공백 뒤에 오지 않는 한 일반 스칼라 안에서 사용될 수 있다는 것입니다. 이는 따옴표 없는 URL과 타임스탬프를 허용합니다. 또한 “a:1”이 키/값 쌍이 아니라 일반 스칼라라는 점에서 혼동의 잠재적 원인이기도 합니다.

값은 그 존재가 “:”로 표시되므로 완전히 비어 있을 수 있다는 점에 유의하십시오.

[144] ns-flow-map-implicit-entry(n,c) ::=
    ns-flow-map-yaml-key-entry(n,c)
  | c-ns-flow-map-empty-key-entry(n,c)
  | c-ns-flow-map-json-key-entry(n,c)

[145] ns-flow-map-yaml-key-entry(n,c) ::=
  ns-flow-yaml-node(n,c)
  (
      (
        s-separate(n,c)?
        c-ns-flow-map-separate-value(n,c)
      )
    | e-node    # ""
  )

[146] c-ns-flow-map-empty-key-entry(n,c) ::=
  e-node    # ""
  c-ns-flow-map-separate-value(n,c)

[147] c-ns-flow-map-separate-value(n,c) ::=
  c-mapping-value    # ':'
  [ lookahead ≠ ns-plain-safe(c) ]
  (
      (
        s-separate(n,c)
        ns-flow-node(n,c)
      )
    | e-node    # ""
  )

예제 7.17 흐름 매핑 분리 값

{
unquoted·:·"separate",
https://foo.com,
omitted value:°,
°:·omitted key,
}

{ "unquoted": "separate",
  "http://foo.com": null,
  "omitted value": null,
  null: "omitted key" }

범례:

JSON 호환성을 보장하기 위해, 흐름 매핑 안의 키가 JSON과 유사하다면, YAML은 뒤따르는 값이 “:”에 인접하여 지정되는 것을 허용합니다. 모든 JSON과 유사한 키는 표시자로 둘러싸이므로 이는 모호성을 일으키지 않습니다. 그러나 이는 가독성을 크게 떨어뜨리므로, YAML 프로세서는 이 경우에도 출력 시 값을 “:”에서 분리해야 합니다. 

[148] c-ns-flow-map-json-key-entry(n,c) ::=
  c-flow-json-node(n,c)
  (
      (
        s-separate(n,c)?
        c-ns-flow-map-adjacent-value(n,c)
      )
    | e-node    # ""
  )

[149] c-ns-flow-map-adjacent-value(n,c) ::=
  c-mapping-value          # ':'
  (
      (
        s-separate(n,c)?
        ns-flow-node(n,c)
      )
    | e-node    # ""
  )

예제 7.18 흐름 매핑 인접 값

{
"adjacent":value,
"readable":·value,
"empty":°
}

{ "adjacent": "value",
  "readable": "value",
  "empty": null }

범례:

매핑이 단일 키/값 쌍을 포함하는 경우, 흐름 시퀀스 안에서 더 간결한 표기법을 사용할 수 있습니다. 이 표기법은 주변의 “{” 및 “}” 문자를 필요로 하지 않습니다. 이 경우 매핑에 대해 어떤 노드 속성도 지정할 수 없다는 점에 유의하십시오.

예제 7.19 단일 쌍 흐름 매핑

[
foo: bar
]

[ { "foo": "bar" } ]

범례:

“?” 표시자가 명시적으로 지정되면, 파싱은 모호하지 않으며 구문은 일반적인 경우와 동일합니다.

[150] ns-flow-pair(n,c) ::=
    (
      c-mapping-key     # '?' (not followed by non-ws char)
      s-separate(n,c)
      ns-flow-map-explicit-entry(n,c)
    )
  | ns-flow-pair-entry(n,c)

예제 7.20 단일 쌍 명시적 항목

[
? foo
 bar : baz
]

[ { "foo bar": "baz" } ]

범례:

“?” 표시자가 생략되면, 파싱은 그것을 암시적 키로 인식하기 위해 그 너머를 살펴보아야 합니다. 필요한 선행 탐색의 양을 제한하기 위해, “:” 표시자는 키의 시작으로부터 최대 1024개의 Unicode 문자 이내에 나타나야 합니다. 또한 키는 한 줄로 제한됩니다.

YAML은 임의의 노드를 키로 사용할 수 있도록 허용한다는 점에 유의하십시오. 특히 키는 시퀀스나 매핑일 수 있습니다. 따라서 위 제한이 없다면 실용적인 단일 패스 파싱은 구현하기 불가능했을 것입니다. 

[151] ns-flow-pair-entry(n,c) ::=
    ns-flow-pair-yaml-key-entry(n,c)
  | c-ns-flow-map-empty-key-entry(n,c)
  | c-ns-flow-pair-json-key-entry(n,c)

[152] ns-flow-pair-yaml-key-entry(n,c) ::=
  ns-s-implicit-yaml-key(FLOW-KEY)
  c-ns-flow-map-separate-value(n,c)

[153] c-ns-flow-pair-json-key-entry(n,c) ::=
  c-s-implicit-json-key(FLOW-KEY)
  c-ns-flow-map-adjacent-value(n,c)

[154] ns-s-implicit-yaml-key(c) ::=
  ns-flow-yaml-node(0,c)
  s-separate-in-line?
  /* At most 1024 characters altogether */

[155] c-s-implicit-json-key(c) ::=
  c-flow-json-node(0,c)
  s-separate-in-line?
  /* At most 1024 characters altogether */

예제 7.21 단일 쌍 암시적 항목

- [ YAML·: separate ]
- [ °: empty key entry ]
- [ {JSON: like}:adjacent ]

[ [ { "YAML": "separate" } ],
  [ { null: "empty key entry" } ],
  [ { { "JSON": "like" }: "adjacent" } ] ]

범례:

예제 7.22 유효하지 않은 암시적 키

[ foo
 bar: invalid,
 "foo_...>1K characters..._bar": invalid ]

ERROR:
- The foo bar key spans multiple lines
- The foo...bar key is too long

7.5. 흐름 노드

JSON과 유사한 흐름 스타일은 모두 명시적인 시작 및 끝 표시자를 가집니다. 이 속성을 가지지 않는 유일한 흐름 스타일은 일반 스칼라입니다. “JSON과 유사한” 스타일 중 실제로 JSON에서 허용되는 것은 없다는 점에 유의하십시오. 큰따옴표 스타일조차 JSON 문자열 형식의 상위 집합입니다. 

[156] ns-flow-yaml-content(n,c) ::=
  ns-plain(n,c)

[157] c-flow-json-content(n,c) ::=
    c-flow-sequence(n,c)
  | c-flow-mapping(n,c)
  | c-single-quoted(n,c)
  | c-double-quoted(n,c)

[158] ns-flow-content(n,c) ::=
    ns-flow-yaml-content(n,c)
  | c-flow-json-content(n,c)

예제 7.23 흐름 콘텐츠

- [ a, b ]
- { a: b }
- "a"
- 'b'
- c

[ [ "a", "b" ],
  { "a": "b" },
  "a",
  "b",
  "c" ]

범례:

완전한 흐름 노드도 선택적 노드 속성을 가집니다. 단, 앵커가 지정된 노드 속성을 참조하는 별칭 노드는 예외입니다. 

[159] ns-flow-yaml-node(n,c) ::=
    c-ns-alias-node
  | ns-flow-yaml-content(n,c)
  | (
      c-ns-properties(n,c)
      (
          (
            s-separate(n,c)
            ns-flow-yaml-content(n,c)
          )
        | e-scalar
      )
    )

[160] c-flow-json-node(n,c) ::=
  (
    c-ns-properties(n,c)
    s-separate(n,c)
  )?
  c-flow-json-content(n,c)

[161] ns-flow-node(n,c) ::=
    c-ns-alias-node
  | ns-flow-content(n,c)
  | (
      c-ns-properties(n,c)
      (
        (
          s-separate(n,c)
          ns-flow-content(n,c)
        )
        | e-scalar
      )
    )

예제 7.24 흐름 노드

- !!str "a"
- 'b'
- &anchor "c"
- *anchor
- !!str°

[ "a",
  "b",
  "c",
  "c",
  "" ]

범례:

제8장. 블록 스타일 생성 규칙

YAML의 블록 스타일은 구조를 나타내기 위해 표시자가 아니라 들여쓰기를 사용합니다. 그 결과 더 사람이 읽기 쉬운(다만 덜 간결한) 표기법이 됩니다.

8.1. 블록 스칼라 스타일

YAML은 두 가지 블록 스칼라 스타일, 즉 리터럴과 접힌 스타일을 제공합니다. 각각은 가독성과 표현력 사이에서 서로 다른 절충을 제공합니다.

8.1.1. 블록 스칼라 헤더

블록 스칼라는 콘텐츠 자체 앞에 오는 헤더 안에 주어지는 몇 가지 표시자로 제어됩니다. 이 헤더 뒤에는 선택적 주석이 있는, 콘텐츠가 아닌 줄바꿈이 옵니다. 이는 주석 뒤에 추가 주석 줄이 이어져서는 안 되는 유일한 경우입니다.

참고: t 변수의 정의는 생성 규칙 매개변수를 참조하십시오. 

[162] c-b-block-header(t) ::=
  (
      (
        c-indentation-indicator
        c-chomping-indicator(t)
      )
    | (
        c-chomping-indicator(t)
        c-indentation-indicator
      )
  )
  s-b-comment

예제 8.1 블록 스칼라 헤더

- | # Empty header↓
 literal
- >1 # Indentation indicator↓
 ·folded
- |+ # Chomping indicator↓
 keep

- >1- # Both indicators↓
 ·strip

[ "literal\n",
  " folded\n",
  "keep\n\n",
  " strip" ]

범례:

8.1.1.1. 블록 들여쓰기 표시자

모든 블록 스칼라는 콘텐츠 들여쓰기 수준을 가집니다. 블록 스칼라의 콘텐츠는 각 줄에서 콘텐츠 들여쓰기 수준까지의 선행 스페이스를 제외합니다.

블록 스칼라에 들여쓰기 표시자가 있으면, 블록 스칼라의 콘텐츠 들여쓰기 수준은 블록 스칼라의 들여쓰기 수준에 들여쓰기 표시자 문자의 정수값을 더한 값과 같습니다.

들여쓰기 표시자가 주어지지 않으면, 콘텐츠 들여쓰기 수준은 콘텐츠의 첫 번째 비-빈 줄에 있는 선행 스페이스 수와 같습니다. 비-빈 줄이 없으면 콘텐츠 들여쓰기 수준은 가장 긴 줄의 스페이스 수와 같습니다.

비-빈 줄이 콘텐츠 들여쓰기 수준 이상인 수의 스페이스로 시작하지 않으면 오류입니다.

선행 빈 줄 중 어느 줄이라도 첫 번째 비-빈 줄보다 더 많은 스페이스를 포함하면 오류입니다.

YAML 프로세서는 감지가 실패할 경우에만 명시적 들여쓰기 표시자를 출력해야 합니다.

[163] c-indentation-indicator ::=
  [x31-x39]    # 1-9

예제 8.2 블록 들여쓰기 표시자

- |°
·detected
- >°
·
··
··# detected
- |1
··explicit
- >°
·→
·detected

[ "detected\n",
  "\n\n# detected\n",
  " explicit\n",
  "\t\ndetected\n" ]

범례:

예제 8.3 유효하지 않은 블록 스칼라 들여쓰기 표시자

- |
··
·text
- >
··text
·text
- |2
·text

ERROR:
- A leading all-space line must
  not have too many spaces.
- A following text line must
  not be less indented.
- The text is less indented
  than the indicated level.

8.1.1.2. 블록 촘핑 표시자

촘핑은 최종 줄바꿈과 후행 빈 줄이 해석되는 방식을 제어합니다. YAML은 세 가지 촘핑 방식을 제공합니다.

제거

제거는 “-” 촘핑 표시자로 지정됩니다. 이 경우 최종 줄바꿈과 모든 후행 빈 줄은 스칼라 콘텐츠에서 제외됩니다.

클립

클립은 명시적 촘핑 표시자가 지정되지 않았을 때 사용되는 기본 동작입니다. 이 경우 최종 줄바꿈 문자는 스칼라 콘텐츠에 보존됩니다. 그러나 모든 후행 빈 줄은 스칼라 콘텐츠에서 제외됩니다.

유지

유지는 “+” 촘핑 표시자로 지정됩니다. 이 경우 최종 줄바꿈과 모든 후행 빈 줄은 스칼라 콘텐츠의 일부로 간주됩니다. 이러한 추가 줄은 접기의 대상이 아닙니다.

사용되는 촘핑 방식은 프레젠테이션 세부 사항이며, 콘텐츠 정보를 전달하는 데 사용되어서는 안 됩니다.

[164]
c-chomping-indicator(STRIP) ::= '-'
c-chomping-indicator(KEEP)  ::= '+'
c-chomping-indicator(CLIP)  ::= ""

블록 스칼라의 최종 줄바꿈 해석은 블록 스칼라 헤더에 지정된 촘핑 표시자로 제어됩니다. 

[165]
b-chomped-last(STRIP) ::= b-non-content  | <end-of-input>
b-chomped-last(CLIP)  ::= b-as-line-feed | <end-of-input>
b-chomped-last(KEEP)  ::= b-as-line-feed | <end-of-input>

예제 8.4 최종 줄바꿈 촘핑

strip: |-
  text↓
clip: |
  text↓
keep: |+
  text↓

{ "strip": "text",
  "clip": "text\n",
  "keep": "text\n" }

범례:

블록 스칼라 뒤에 오는 후행 빈 줄의 해석도 블록 스칼라 헤더에 지정된 촘핑 표시자로 제어됩니다. 

[166]
l-chomped-empty(n,STRIP) ::= l-strip-empty(n)
l-chomped-empty(n,CLIP)  ::= l-strip-empty(n)
l-chomped-empty(n,KEEP)  ::= l-keep-empty(n)

[167] l-strip-empty(n) ::=
  (
    s-indent-less-or-equal(n)
    b-non-content
  )*
  l-trail-comments(n)?

[168] l-keep-empty(n) ::=
  l-empty(n,BLOCK-IN)*
  l-trail-comments(n)?

명시적 주석 줄은 후행 빈 줄 뒤에 올 수 있습니다. 모호성을 방지하기 위해, 그러한 첫 번째 주석 줄은 블록 스칼라 콘텐츠보다 덜 들여쓰기되어야 합니다. 추가 주석 줄이 있다면, 그것들은 이러한 제한을 받지 않습니다. 이는 주석 줄의 들여쓰기가 제약되는 유일한 경우입니다. 

[169] l-trail-comments(n) ::=
  s-indent-less-than(n)
  c-nb-comment-text
  b-comment
  l-comment*

예제 8.5 후행 줄 촘핑

# Strip
  # Comments:
strip: |-
  # text↓
··⇓
·# Clip
··# comments:
↓
clip: |
  # text↓
·↓
·# Keep
··# comments:
↓
keep: |+
  # text↓
↓
·# Trail
··# comments.

{ "strip": "# text",
  "clip": "# text\n",
  "keep": "# text\n\n" }

범례:

블록 스칼라가 빈 줄만으로 구성된 경우, 이러한 줄은 후행 줄로 간주되며 따라서 촘핑의 영향을 받습니다.

예제 8.6 빈 스칼라 촘핑

strip: >-
↓
clip: >
↓
keep: |+
↓

{ "strip": "",
  "clip": "",
  "keep": "\n" }

범례:

8.1.2. 리터럴 스타일

리터럴 스타일은 “|” 표시자로 나타냅니다. 이는 가장 단순하고, 가장 제한적이며, 가장 읽기 쉬운 스칼라 스타일입니다. 

[170] c-l+literal(n) ::=
  c-literal                # '|'
  c-b-block-header(t)
  l-literal-content(n+m,t)

예제 8.7 리터럴 스칼라

|↓
·literal↓
·→text↓
↓

"literal\n\ttext\n"

범례:

리터럴 스칼라 안에서는 모든 (들여쓰기된) 문자가 콘텐츠로 간주되며, 공백 문자도 포함됩니다. 모든 줄바꿈 문자가 정규화된다는 점에 유의하십시오. 또한 빈 줄은 접히지 않지만, 최종 줄바꿈과 후행 빈 줄은 촘핑됩니다.

리터럴 스칼라 안에서는 문자를 이스케이프할 방법이 없습니다. 이로 인해 리터럴 스칼라는 인쇄 가능 문자로 제한됩니다. 또한 긴 리터럴 줄을 나눌 방법도 없습니다.

[171] l-nb-literal-text(n) ::=
  l-empty(n,BLOCK-IN)*
  s-indent(n) nb-char+

[172] b-nb-literal-next(n) ::=
  b-as-line-feed
  l-nb-literal-text(n)

[173] l-literal-content(n,t) ::=
  (
    l-nb-literal-text(n)
    b-nb-literal-next(n)*
    b-chomped-last(t)
  )?
  l-chomped-empty(n,t)

예제 8.8 리터럴 콘텐츠

|
·
··
··literal↓
···↓
··
··text↓
↓
·# Comment

"\n\nliteral\n·\n\ntext\n"

범례:

8.1.3. 접힌 스타일

접힌 스타일은 “>” 표시자로 나타냅니다. 이는 리터럴 스타일과 비슷하지만, 접힌 스칼라는 줄 접기의 대상이 됩니다. 

[174] c-l+folded(n) ::=
  c-folded                 # '>'
  c-b-block-header(t)
  l-folded-content(n+m,t)

예제 8.9 접힌 스칼라

>↓
·folded↓
·text↓
↓

"folded text\n"

범례:

접기를 사용하면 두 비-스페이스 문자를 하나의 스페이스 문자가 구분하는 모든 위치에서 긴 줄을 나눌 수 있습니다. 

[175] s-nb-folded-text(n) ::=
  s-indent(n)
  ns-char
  nb-char*

[176] l-nb-folded-lines(n) ::=
  s-nb-folded-text(n)
  (
    b-l-folded(n,BLOCK-IN)
    s-nb-folded-text(n)
  )*

예제 8.10 접힌 줄

>

·folded↓
·line↓
↓
·next
·line↓
   * bullet

   * list
   * lines

·last↓
·line↓

# Comment

"\nfolded line\nnext line\n  \
* bullet\n \n  * list\n  \
* lines\n\nlast line\n"

범례:

(다음 세 예제는 이 예제를 중복하며, 각각 서로 다른 생성 규칙을 강조합니다.)

공백 문자로 시작하는 줄 (더 많이 들여쓴 줄)은 접히지 않습니다. 

[177] s-nb-spaced-text(n) ::=
  s-indent(n)
  s-white
  nb-char*

[178] b-l-spaced(n) ::=
  b-as-line-feed
  l-empty(n,BLOCK-IN)*

[179] l-nb-spaced-lines(n) ::=
  s-nb-spaced-text(n)
  (
    b-l-spaced(n)
    s-nb-spaced-text(n)
  )*

예제 8.11 더 많이 들여쓴 줄

>

 folded
 line

 next
 line
···* bullet↓
↓
···* list↓
···* lines↓

 last
 line

# Comment

"\nfolded line\nnext line\n  \
* bullet\n \n  * list\n  \
* lines\n\nlast line\n"

범례:

접힌 줄과 더 많이 들여쓴 줄을 분리하는 줄바꿈 및 빈 줄도 접히지 않습니다. 

[180] l-nb-same-lines(n) ::=
  l-empty(n,BLOCK-IN)*
  (
      l-nb-folded-lines(n)
    | l-nb-spaced-lines(n)
  )

[181] l-nb-diff-lines(n) ::=
  l-nb-same-lines(n)
  (
    b-as-line-feed
    l-nb-same-lines(n)
  )*

예제 8.12 빈 분리 줄

>
↓
 folded
 line↓
↓
 next
 line↓
   * bullet

   * list
   * lines↓
↓
 last
 line

# Comment

"\nfolded line\nnext line\n  \
* bullet\n \n  * list\n  \
* lines\n\nlast line\n"

범례:

최종 줄바꿈과 후행 빈 줄이 있다면, 그것들은 촘핑의 대상이며 결코 접히지 않습니다. 

[182] l-folded-content(n,t) ::=
  (
    l-nb-diff-lines(n)
    b-chomped-last(t)
  )?
  l-chomped-empty(n,t)

예제 8.13 최종 빈 줄

>

 folded
 line

 next
 line
   * bullet

   * list
   * lines

 last
 line↓
↓
# Comment

"\nfolded line\nnext line\n  \
* bullet\n \n  * list\n  \
* lines\n\nlast line\n"

범례:

8.2. 블록 컬렉션 스타일

가독성을 위해 블록 컬렉션 스타일은 어떤 표시자로도 나타내지 않습니다. 대신 YAML은 블록 컬렉션을 일반 스칼라와 구별하기 위해, 키/값 쌍 또는 시퀀스 항목이 보일 때만 구별하는 선행 탐색 방식을 사용합니다.

8.2.1. 블록 시퀀스

블록 시퀀스는 단순히 일련의 노드이며, 각 노드는 선행 “-” 표시자로 나타냅니다. “-” 표시자는 노드와 공백으로 분리되어야 합니다. 이렇게 하면 “-” 뒤에 비-스페이스 문자가 오는 경우(예: “-42”) 이를 일반 스칼라의 첫 문자로 사용할 수 있습니다. 

[183] l+block-sequence(n) ::=
  (
    s-indent(n+1+m)
    c-l-block-seq-entry(n+1+m)
  )+

[184] c-l-block-seq-entry(n) ::=
  c-sequence-entry    # '-'
  [ lookahead ≠ ns-char ]
  s-l+block-indented(n,BLOCK-IN)

예제 8.14 블록 시퀀스

block sequence:
··- one↓
  - two : three↓

{ "block sequence": [
    "one",
    { "two": "three" } ] }

범례:

항목 노드는 완전히 비어 있거나, 중첩된 블록 노드이거나, 간결한 인라인 표기법을 사용할 수 있습니다. 간결한 표기법은 항목 자체가 중첩된 블록 컬렉션인 경우 사용할 수 있습니다. 이 경우 “-” 표시자와 뒤따르는 스페이스는 모두 중첩된 컬렉션의 들여쓰기 일부로 간주됩니다. 이러한 컬렉션에는 노드 속성을 지정할 수 없다는 점에 유의하십시오. 

[185] s-l+block-indented(n,c) ::=
    (
      s-indent(m)
      (
          ns-l-compact-sequence(n+1+m)
        | ns-l-compact-mapping(n+1+m)
      )
    )
  | s-l+block-node(n,c)
  | (
      e-node    # ""
      s-l-comments
    )

[186] ns-l-compact-sequence(n) ::=
  c-l-block-seq-entry(n)
  (
    s-indent(n)
    c-l-block-seq-entry(n)
  )*

예제 8.15 블록 시퀀스 항목 유형

-° # Empty
- |
 block node
-·- one # Compact
··- two # sequence
- one: two # Compact mapping

[ null,
  "block node\n",
  [ "one", "two" ],
  { "one": "two" } ]

범례:

8.2.2. 블록 매핑

블록 매핑은 각각 키/값 쌍을 제시하는 일련의 항목입니다.

[187] l+block-mapping(n) ::=
  (
    s-indent(n+1+m)
    ns-l-block-map-entry(n+1+m)
  )+

예제 8.16 블록 매핑

block mapping:
·key: value↓

{ "block mapping": {
    "key": "value" } }

범례:

“?” 표시자가 지정되면, 선택적 값 노드는 “:” 표시자로 나타나는 별도 줄에 지정해야 합니다. 여기서 YAML은 블록 시퀀스 항목에 대해 위에서 설명한 것과 같은 간결한 인라인 표기법을 허용한다는 점에 유의하십시오. 

[188] ns-l-block-map-entry(n) ::=
    c-l-block-map-explicit-entry(n)
  | ns-l-block-map-implicit-entry(n)

[189] c-l-block-map-explicit-entry(n) ::=
  c-l-block-map-explicit-key(n)
  (
      l-block-map-explicit-value(n)
    | e-node                        # ""
  )

[190] c-l-block-map-explicit-key(n) ::=
  c-mapping-key                     # '?' (not followed by non-ws char)
  s-l+block-indented(n,BLOCK-OUT)

[191] l-block-map-explicit-value(n) ::=
  s-indent(n)
  c-mapping-value                   # ':' (not followed by non-ws char)
  s-l+block-indented(n,BLOCK-OUT)

예제 8.17 명시적 블록 매핑 항목

? explicit key # Empty value↓°
? |
  block key↓
:·- one # Explicit compact
··- two # block value↓

{ "explicit key": null,
  "block key\n": [
    "one",
    "two" ] }

범례:

“?” 표시자가 생략되면, 파싱은 흐름 매핑의 단일 키/값 쌍에서와 같은 방식으로, 암시적 키 너머를 살펴보아야 합니다. 따라서 그러한 키는 같은 제한을 받습니다. 즉 한 줄로 제한되고, 1024개를 초과하는 Unicode 문자에 걸쳐서는 안 됩니다. 

[192] ns-l-block-map-implicit-entry(n) ::=
  (
      ns-s-block-map-implicit-key
    | e-node    # ""
  )
  c-l-block-map-implicit-value(n)

[193] ns-s-block-map-implicit-key ::=
    c-s-implicit-json-key(BLOCK-KEY)
  | ns-s-implicit-yaml-key(BLOCK-KEY)

이 경우 값은 암시적 키와 같은 줄에 지정할 수 있습니다. 그러나 블록 매핑에서 값은 “:”에 결코 인접해서는 안 된다는 점에 유의하십시오. 이는 가독성을 크게 떨어뜨리고, 흐름 매핑의 경우와 달리 JSON 호환성을 위해 필요하지 않기 때문입니다.

인라인 값을 위한 간결한 표기법은 없습니다. 또한 암시적 키와 그 뒤의 값이 둘 다 비어 있을 수는 있지만, “:” 표시자는 필수입니다. 이는 여러 줄 일반 스칼라와의 잠재적 모호성을 방지합니다. 

[194] c-l-block-map-implicit-value(n) ::=
  c-mapping-value           # ':' (not followed by non-ws char)
  (
      s-l+block-node(n,BLOCK-OUT)
    | (
        e-node    # ""
        s-l-comments
      )
  )

예제 8.18 암시적 블록 매핑 항목

plain key: in-line value
°:° # Both empty
"quoted key":
- entry

{ "plain key": "in-line value",
  null: null,
  "quoted key": [ "entry" ] }

범례:

간결한 인라인 표기법도 사용할 수 있습니다. 이 간결한 표기법은 블록 시퀀스 및 명시적 블록 매핑 항목 안에 중첩될 수 있습니다. 이러한 중첩된 매핑에는 노드 속성을 지정할 수 없다는 점에 유의하십시오.

[195] ns-l-compact-mapping(n) ::=
  ns-l-block-map-entry(n)
  (
    s-indent(n)
    ns-l-block-map-entry(n)
  )*

예제 8.19 간결한 블록 매핑

- sun: yellow↓
- ? earth: blue↓
  : moon: white↓

[ { "sun": "yellow" },
  { { "earth": "blue" }:
      { "moon": "white" } } ]

범례:

8.2.3. 블록 노드

YAML은 흐름 노드가 블록 컬렉션 안에 포함되는 것을 허용합니다(그 반대는 허용하지 않습니다). 흐름 노드는 부모 블록 컬렉션보다 적어도 하나 더 많은 스페이스로 들여쓰기되어야 합니다. 흐름 노드는 다음 줄에서 시작할 수도 있다는 점에 유의하십시오.

바로 이 지점에서 파싱은 일반 스칼라와, 중첩된 블록 매핑을 시작하는 암시적 키를 구별해야 합니다. 

[196] s-l+block-node(n,c) ::=
    s-l+block-in-block(n,c)
  | s-l+flow-in-block(n)

[197] s-l+flow-in-block(n) ::=
  s-separate(n+1,FLOW-OUT)
  ns-flow-node(n+1,FLOW-OUT)
  s-l-comments

예제 8.20 블록 노드 유형

-↓
··"flow in block"↓
-·>
 Block scalar↓
-·!!map # Block collection
  foo : bar↓

[ "flow in block",
  "Block scalar\n",
  { "foo": "bar" } ]

범례:

블록 노드의 속성은 여러 줄에 걸칠 수 있습니다. 이 경우 블록 컬렉션 항목의 들여쓰기와 관계없이, 블록 컬렉션보다 적어도 하나 더 많은 스페이스로 들여쓰기되어야 합니다. 

[198] s-l+block-in-block(n,c) ::=
    s-l+block-scalar(n,c)
  | s-l+block-collection(n,c)

[199] s-l+block-scalar(n,c) ::=
  s-separate(n+1,c)
  (
    c-ns-properties(n+1,c)
    s-separate(n+1,c)
  )?
  (
      c-l+literal(n)
    | c-l+folded(n)
  )

예제 8.21 블록 스칼라 노드

literal: |2
··value
folded:↓
···!foo
··>1
·value

{ "literal": "value",
  "folded": !<!foo> "value" }

범례:

사람들은 “-” 표시자를 들여쓰기로 인식하므로, 중첩된 블록 시퀀스는 이를 보정하기 위해 하나 적은 스페이스로 들여쓰기될 수 있습니다. 물론 다른 블록 시퀀스 안에 중첩된 경우는 예외입니다 ([BLOCK-OUT 컨텍스트] 대 [BLOCK-IN 컨텍스트]). 

[200] s-l+block-collection(n,c) ::=
  (
    s-separate(n+1,c)
    c-ns-properties(n+1,c)
  )?
  s-l-comments
  (
      seq-space(n,c)
    | l+block-mapping(n)
  )

[201] seq-space(n,BLOCK-OUT) ::= l+block-sequence(n-1)
    seq-space(n,BLOCK-IN)  ::= l+block-sequence(n)

예제 8.22 블록 컬렉션 노드

sequence: !!seq
- entry
- !!seq
 - nested
mapping: !!map
 foo: bar

{ "sequence": [
    "entry",
    [ "nested" ] ],
  "mapping": { "foo": "bar" } }

범례:

제9장. 문서 스트림 생성 규칙

9.1. 문서

YAML 문자 스트림은 여러 문서를 포함할 수 있습니다. 각 문서는 나머지 문서와 완전히 독립적입니다.

9.1.1. 문서 접두사

문서 앞에는 문자 인코딩과 선택적 주석 줄을 지정하는 접두사가 올 수 있습니다. 스트림 안의 모든 문서는 같은 문자 인코딩을 사용해야 한다는 점에 유의하십시오. 그러나 스트림 안의 각 문서에 대해 바이트 순서 표시를 사용하여 인코딩을 다시 지정하는 것은 유효합니다.

선택적 접두사의 존재가 반드시 실제 문서의 존재를 나타내는 것은 아닙니다.

[202] l-document-prefix ::=
  c-byte-order-mark?
  l-comment*

예제 9.1 문서 접두사

⇔# Comment
# lines
Document

"Document"

범례:

9.1.2. 문서 마커

지시문을 사용하면 잠재적 모호성이 생깁니다. 줄의 시작에 “%” 문자가 있는 것은 유효합니다(예: 일반 스칼라의 두 번째 줄 첫 문자). 그렇다면 실제 지시문과 우연히 “%” 문자로 시작하는 콘텐츠 줄을 어떻게 구별할 수 있을까요?

해결책은 지시문 처리를 제어하기 위해 두 개의 특수 마커 줄을 사용하는 것입니다. 하나는 문서 시작에, 하나는 끝에 둡니다.

문서 시작에서 “%” 문자로 시작하는 줄은 지시문으로 간주됩니다. (비어 있을 수도 있는) 지시문 목록은 지시문 종료 마커 줄로 끝납니다. 이 마커 뒤의 줄은 “%”를 첫 문자로 안전하게 사용할 수 있습니다.

문서 끝에서는 문서 종료 마커 줄을 사용하여 파서가 다시 지시문 검색을 시작하도록 알립니다.

이 선택적 문서 접미사의 존재가 반드시 실제 다음 문서의 존재를 나타내는 것은 아닙니다.

따라서 실제 콘텐츠 줄은 당연히 이 두 마커 중 하나로 시작하는 것이 금지됩니다.

[203] c-directives-end ::= "---"

[204] c-document-end ::=
  "..."    # (not followed by non-ws char)

[205] l-document-suffix ::=
  c-document-end
  s-l-comments

[206] c-forbidden ::=
  <start-of-line>
  (
      c-directives-end
    | c-document-end
  )
  (
      b-char
    | s-white
    | <end-of-input>
  )

예제 9.2 문서 마커

%YAML 1.2
---
Document
... # Suffix

"Document"

범례:

9.1.3. 기본 문서

기본 문서는 어떤 지시문이나 마커 줄로도 시작하지 않습니다. 이러한 문서는 콘텐츠 이외의 어떤 것도 포함하지 않으므로 매우 “깨끗”합니다. 이 경우 첫 번째 비주석 줄은 첫 문자로 “%”를 사용할 수 없습니다.

문서 노드는 -1개의 스페이스로 들여쓰기된 부모를 가진 것처럼 들여쓰기됩니다. 노드는 자신의 부모 노드보다 더 들여쓰기되어야 하므로, 이를 통해 문서의 노드는 0개 이상의 스페이스로 들여쓰기될 수 있습니다. 

[207] l-bare-document ::=
  s-l+block-node(-1,BLOCK-IN)
  /* Excluding c-forbidden content */

예제 9.3 기본 문서

Bare
document
...
# No document
...
|
%!PS-Adobe-2.0 # Not the first line

"Bare document"
---
"%!PS-Adobe-2.0\n"

범례:

9.1.4. 명시적 문서

명시적 문서는 명시적 지시문 종료 마커 줄로 시작하지만 지시문은 없습니다. 문서의 존재가 이 마커로 표시되므로, 문서 자체는 완전히 비어 있을 수 있습니다. 

[208] l-explicit-document ::=
  c-directives-end
  (
      l-bare-document
    | (
        e-node    # ""
        s-l-comments
      )
  )

예제 9.4 명시적 문서

---
{ matches
% : 20 }
...
---
# Empty
...

{ "matches %": 20 }
---
null

범례:

9.1.5. 지시문 문서

지시문 문서는 일부 지시문으로 시작하며, 그 뒤에는 명시적 지시문 종료 마커 줄이 옵니다. 

[209] l-directive-document ::=
  l-directive+
  l-explicit-document

예제 9.5 지시문 문서

%YAML 1.2
--- |
%!PS-Adobe-2.0
...
%YAML 1.2
---
# Empty
...

"%!PS-Adobe-2.0\n"
---
null

범례:

9.2. 스트림

YAML 스트림은 0개 이상의 문서로 구성됩니다. 이어지는 문서에는 어떤 형태의 분리 마커 줄이 필요합니다. 문서가 문서 종료 마커 줄로 끝나지 않았다면, 다음 문서는 지시문 종료 마커 줄로 시작해야 합니다. 

[210] l-any-document ::=
    l-directive-document
  | l-explicit-document
  | l-bare-document

[211] l-yaml-stream ::=
  l-document-prefix*
  l-any-document?
  (
      (
        l-document-suffix+
        l-document-prefix*
        l-any-document?
      )
    | c-byte-order-mark
    | l-comment
    | l-explicit-document
  )*

예제 9.6 스트림

Document
---
# Empty
...
%YAML 1.2
---
matches %: 20

"Document"
---
null
---
{ "matches %": 20 }

범례:

바이트 시퀀스는 전체적으로 위의 l-yaml-stream 생성 규칙을 준수하면 올바른 형식의 스트림입니다.

제10장. 권장 스키마

YAML 스키마는 태그 집합과 비특정 태그를 해석하는 메커니즘의 조합입니다.

10.1. Failsafe 스키마

Failsafe 스키마는 모든 YAML 문서에서 동작하는 것이 보장됩니다. 따라서 범용 YAML 도구에 권장되는 스키마입니다. 그러므로 YAML 프로세서는 최소한 옵션으로라도 이 스키마를 지원해야 합니다.

10.1.1. 태그

10.1.1.1. 일반 매핑

URI

tag:yaml.org,2002:map

종류

매핑.

정의

각 키가 연결 안에서 고유하며 정확히 하나의 값에 매핑되는 연관 컨테이너를 나타냅니다. YAML은 키의 타입에 제한을 두지 않습니다. 특히 스칼라로 제한되지 않습니다. 네이티브 타입에 대한 바인딩 예에는 Perl의 hash, Python의 dictionary, Java의 Hashtable이 포함됩니다.

예제 10.1 !!map 예

Block style: !!map
  Clark : Evans
  Ingy  : döt Net
  Oren  : Ben-Kiki

Flow style: !!map { Clark: Evans, Ingy: döt Net, Oren: Ben-Kiki }

10.1.1.2. 일반 시퀀스

URI

tag:yaml.org,2002:seq

종류

시퀀스.

정의

0부터 시작하는 순차 정수로 색인되는 컬렉션을 나타냅니다. 네이티브 타입에 대한 바인딩 예에는 Perl의 array, Python의 list 또는 tuple, Java의 array 또는 Vector가 포함됩니다.

예제 10.2 !!seq 예

Block style: !!seq
- Clark Evans
- Ingy döt Net
- Oren Ben-Kiki

Flow style: !!seq [ Clark Evans, Ingy döt Net, Oren Ben-Kiki ]

10.1.1.3. 일반 문자열

URI

tag:yaml.org,2002:str

종류

스칼라.

정의

0개 이상의 Unicode 문자 시퀀스인 Unicode 문자열을 나타냅니다. 이 타입은 보통 네이티브 언어의 문자열 타입에 바인딩되며, 그러한 타입이 없는 언어(예: C)에서는 문자 배열에 바인딩됩니다.

정규 형식:

명백한 형식입니다.

예제 10.3 !!str 예

Block style: !!str |-
  String: just a theory.

Flow style: !!str "String: just a theory."

10.1.2. 태그 해석

“!” 비특정 태그를 가진 모든 노드는 표준 관례에 따라 그 종류에 맞게 “tag:yaml.org,2002:seq”, “tag:yaml.org,2002:map” 또는 “tag:yaml.org,2002:str”로 해석됩니다.

“?” 비특정 태그를 가진 모든 노드는 해석되지 않은 상태로 남습니다. 이는 애플리케이션이 부분 표현을 처리하도록 제약합니다.

10.2. JSON 스키마

JSON 스키마는 대부분의 현대 컴퓨터 언어의 최소 공통분모이며 JSON 파일 파싱을 허용합니다. 그러므로 YAML 프로세서는 최소한 옵션으로라도 이 스키마를 지원해야 합니다. 또한 다른 스키마도 이를 기반으로 할 것을 강력히 권장합니다.

10.2.1. 태그

JSON 스키마는 failsafe 스키마가 정의한 것에 더해 다음 태그를 사용합니다.

10.2.1.1. Null

URI

tag:yaml.org,2002:null

종류

스칼라.

정의

값의 부재를 나타냅니다. 이는 일반적으로 네이티브 null 유사 값(예: Perl의 undef, Python의 None)에 바인딩됩니다. null은 빈 문자열과 다르다는 점에 유의하십시오. 또한 어떤 키와 null 값을 가진 매핑 항목은 유효하며, 매핑 안에 해당 키가 없는 것과 다릅니다.

정규 형식

null.

예제 10.4 !!null 예

!!null null: value for null key
key with null value: !!null null

10.2.1.2. Boolean

URI

tag:yaml.org,2002:bool

종류

스칼라.

정의

true/false 값을 나타냅니다. 네이티브 Boolean 타입이 없는 언어(예: C)에서는 일반적으로 true에는 1, false에는 0을 사용하여 네이티브 정수 타입에 바인딩됩니다.

정규 형식

true 또는 false 중 하나입니다.

예제 10.5 !!bool 예

YAML is a superset of JSON: !!bool true
Pluto is a planet: !!bool false

10.2.1.3. Integer

URI

tag:yaml.org,2002:int

종류

스칼라.

정의

임의 크기의 유한한 수학적 정수를 나타냅니다. 이 타입의 스칼라는 가능하다면 네이티브 정수 데이터 타입에 바인딩되어야 합니다.

일부 언어(예: Perl)는 정수와 부동 소수점 값을 모두 허용하는 “number” 타입만 제공합니다. YAML 프로세서는 왕복 변환이 제대로 되는 한 정수에 그러한 타입을 사용할 수 있습니다.

일부 언어(예: C)에서는 정수가 네이티브 타입의 저장 용량을 초과할 수 있습니다. YAML 프로세서는 그러한 값을 오류로 거부하거나, 경고와 함께 잘라내거나, 왕복 변환을 위한 다른 방식을 찾을 수 있습니다. 일반적으로 32개의 이진 숫자로 표현할 수 있는 정수는 대부분의 시스템을 통해 안전하게 왕복 변환될 수 있습니다.

정규 형식

음수 값에는 선행 “-” 문자를 사용하는 십진 정수 표기법이며, 정규식 0 | -? [1-9] [0-9]*과 일치합니다.

예제 10.6 !!int 예

negative: !!int -12
zero: !!int 0
positive: !!int 34

10.2.1.4. 부동 소수점

URI

tag:yaml.org,2002:float

종류

스칼라.

정의

세 가지 특수 값(양의 무한대, 음의 무한대, “숫자가 아님”)을 포함하는 실수의 근삿값을 나타냅니다.

일부 언어(예: Perl)는 정수와 부동 소수점 값을 모두 허용하는 “number” 타입만 제공합니다. YAML 프로세서는 왕복 변환이 제대로 되는 한 부동 소수점 수에 그러한 타입을 사용할 수 있습니다.

모든 부동 소수점 값을 주어진 네이티브 타입에 정확히 저장할 수 있는 것은 아닙니다. 따라서 float 값은 왕복 변환될 때 “작은 양”만큼 바뀔 수 있습니다. 지원되는 범위와 정확도는 구현에 따라 다르지만, 32비트 IEEE float는 안전해야 합니다. YAML은 특정 정확도를 지정하지 않으므로, 부동 소수점 매핑 키를 사용할 때는 매우 주의해야 하며 권장되지 않습니다.

정규 형식

0, .inf, -.inf, .nan 중 하나이거나, 다음 정규식과 일치하는 과학적 표기법입니다.
-? [1-9] ( \. [0-9]* [1-9] )? ( e [-+] [1-9] [0-9]* )?.

예제 10.7 !!float 예

negative: !!float -1
zero: !!float 0
positive: !!float 2.3e4
infinity: !!float .inf
not a number: !!float .nan

10.2.2. 태그 해석

JSON 스키마의 태그 해석은 failsafe 스키마의 태그 해석을 확장한 것입니다.

“!” 비특정 태그를 가진 모든 노드는 표준 관례에 따라 그 종류에 맞게 “tag:yaml.org,2002:seq”, “tag:yaml.org,2002:map” 또는 “tag:yaml.org,2002:str”로 해석됩니다.

“?” 비특정 태그를 가진 컬렉션(즉, 태그가 없는 컬렉션)은 그 종류에 따라 “tag:yaml.org,2002:seq” 또는 “tag:yaml.org,2002:map”으로 해석됩니다.

“?” 비특정 태그를 가진 스칼라(즉, 일반 스칼라)는 정규식 목록과 매칭됩니다(첫 번째 일치가 우선이며, 예를 들어 0은 !!int로 해석됩니다). 원칙적으로 JSON 파일은 이러한 정규식 중 적어도 하나와 일치하지 않는 스칼라를 포함해서는 안 됩니다. 따라서 YAML 프로세서는 이를 오류로 간주해야 합니다.

정규식 해석되는 태그
null tag:yaml.org,2002:null
true | false tag:yaml.org,2002:bool
-? ( 0 | [1-9] [0-9]* ) tag:yaml.org,2002:int
-? ( 0 | [1-9] [0-9]* ) ( \. [0-9]* )? ( [eE] [-+]? [0-9]+ )? tag:yaml.org,2002:float
* 오류

참고: float의 정규식은 JSON 명세의 정규식과 정확히 일치하지 않습니다. JSON 명세에서는 점 뒤에 적어도 하나의 숫자가 필요합니다: ( \. [0-9]+ ). YAML 1.2 명세는 JSON 동작과 일치하려 했지만, 이는 1.2.2 명세에서 처리할 수 없습니다.

예제 10.8 JSON 태그 해석

A null: null
Booleans: [ true, false ]
Integers: [ 0, -0, 3, -19 ]
Floats: [ 0., -0.0, 12e03, -2E+05 ]
Invalid: [ True, Null,
  0o7, 0x3A, +12.3 ]

{ "A null": null,
  "Booleans": [ true, false ],
  "Integers": [ 0, 0, 3, -19 ],
  "Floats": [ 0.0, -0.0, 12000, -200000 ],
  "Invalid": [ "True", "Null",
    "0o7", "0x3A", "+12.3" ] }

10.3. 코어 스키마

코어 스키마는 JSON 스키마의 확장으로, 같은 타입을 더 사람이 읽기 쉬운 방식으로 제시할 수 있게 합니다. 이는 YAML 프로세서가 별도 지시가 없는 한 사용해야 하는 권장 기본 스키마입니다. 또한 다른 스키마도 이를 기반으로 할 것을 강력히 권장합니다.

10.3.1. 태그

코어 스키마는 JSON 스키마와 같은 태그를 사용합니다.

10.3.2. 태그 해석

코어 스키마의 태그 해석은 JSON 스키마 태그 해석의 확장입니다.

“!” 비특정 태그를 가진 모든 노드는 표준 관례에 따라 그 종류에 맞게 “tag:yaml.org,2002:seq”, “tag:yaml.org,2002:map” 또는 “tag:yaml.org,2002:str”로 해석됩니다.

“?” 비특정 태그를 가진 컬렉션(즉, 태그가 없는 컬렉션)은 그 종류에 따라 “tag:yaml.org,2002:seq” 또는 “tag:yaml.org,2002:map”으로 해석됩니다.

“?” 비특정 태그를 가진 스칼라(즉, 일반 스칼라)는 확장된 정규식 목록과 매칭됩니다. 그러나 이 경우 어떤 정규식도 일치하지 않으면, 스칼라는 tag:yaml.org,2002:str로 해석됩니다(즉, 문자열로 간주됩니다).

정규식 해석되는 태그
null | Null | NULL | ~ tag:yaml.org,2002:null
/* Empty */ tag:yaml.org,2002:null
true | True | TRUE | false | False | FALSE tag:yaml.org,2002:bool
[-+]? [0-9]+ tag:yaml.org,2002:int (10진수)
0o [0-7]+ tag:yaml.org,2002:int (8진수)
0x [0-9a-fA-F]+ tag:yaml.org,2002:int (16진수)
[-+]? ( \. [0-9]+ | [0-9]+ ( \. [0-9]* )? ) ( [eE] [-+]? [0-9]+ )? tag:yaml.org,2002:float (숫자)
[-+]? ( \.inf | \.Inf | \.INF ) tag:yaml.org,2002:float (무한대)
\.nan | \.NaN | \.NAN tag:yaml.org,2002:float (숫자가 아님)
* tag:yaml.org,2002:str (기본값)

예제 10.9 코어 태그 해석

A null: null
Also a null: # Empty
Not a null: ""
Booleans: [ true, True, false, FALSE ]
Integers: [ 0, 0o7, 0x3A, -19 ]
Floats: [
  0., -0.0, .5, +12e03, -2E+05 ]
Also floats: [
  .inf, -.Inf, +.INF, .NAN ]

{ "A null": null,
  "Also a null": null,
  "Not a null": "",
  "Booleans": [ true, true, false, false ],
  "Integers": [ 0, 7, 58, -19 ],
  "Floats": [
    0.0, -0.0, 0.5, 12000, -200000 ],
  "Also floats": [
    Infinity, -Infinity, Infinity, NaN ] }

10.4. 기타 스키마

위의 권장 스키마 중 어느 것도 임의의 명시적 태그 사용을 배제하지 않습니다. 따라서 특정 프로그래밍 언어를 위한 YAML 프로세서는 일반적으로 언어의 네이티브 데이터 구조에 직접 매핑되는 어떤 형태의 로컬 태그 (예: !ruby/object:Set)를 제공합니다.

그러한 로컬 태그는 임시 애플리케이션에는 유용하지만, 안정적이고 상호 운용 가능한 교차-애플리케이션 또는 교차 플랫폼 데이터 교환에는 충분하지 않습니다.

상호 운용 가능한 스키마는 서로 다른 프로그래밍 언어에서 같은 데이터를 나타내는 전역 태그(URI)를 사용합니다. 또한 상호 운용 가능한 스키마는 추가적인 태그 해석 규칙을 제공할 수 있습니다. 그러한 규칙은 추가 정규식을 제공할 수 있을 뿐 아니라, 노드로 가는 경로를 고려할 수도 있습니다. 이를 통해 상호 운용 가능한 스키마는 태그가 없는 노드를 사용할 수 있습니다.

그러한 스키마는 위에서 정의한 코어 스키마를 기반으로 할 것을 강력히 권장합니다.

참조 링크

  1. YAML 언어 개발 팀 ↩

  2. GitHub의 YAML 명세 ↩

  3. YAML Ain’t Markup Language (YAML™) 버전 1.2 ↩ ↩2

  4. Unicode – 텍스트와 이모지를 위한 세계 표준 ↩

  5. YAML Core 메일링 리스트 ↩

  6. SML-DEV 메일링 리스트 아카이브 ↩

  7. Data::Denter - Data::Dumper와 Storable의 (폐기된) 대안 ↩

  8. YAML Ain’t Markup Language (YAML™) 버전 1.1 ↩

  9. JSON 데이터 교환 구문 ↩

  10. PyYAML - Python용 YAML 파서 및 이미터 ↩

  11. LibYAML - YAML 파싱 및 출력을 위한 C 라이브러리 ↩

  12. Request for Comments 요약 ↩

  13. 방향 그래프 ↩

  14. ‘tag’ URI 스킴 ↩

  15. Wikipedia - C0 및 C1 제어 코드 ↩

  16. Wikipedia - Universal Character Set characters #Surrogates ↩

  17. UTF-8, UTF-16, UTF-32 및 BOM ↩

  18. Uniform Resource Identifiers (URI) ↩