关于YAML规范中“formatted content”定位的困惑与求证

Hi Luca, great question—this is definitely one of those nuanced parts of the YAML spec that can trip even experienced users up! Let me walk through my understanding to help untangle this confusion:

先明确三个核心处理阶段的边界 #

Let's start by grounding ourselves in what each stage of YAML processing is responsible for, since that's where the confusion around "formatted content" usually starts:

• Representation Stage: This is the semantic heart of YAML. The unique key constraint for mappings here requires clear equality checks between scalars, which is why tags must define a canonical form for scalar content. As the spec notes in section 3.2.1.3:

  "This form is a Unicode character string which also presents the same content…."
  This canonical form is what ensures two semantically identical scalars (even if they look different in presentation) are treated as equal in the representation graph.

• Serialization Stage: This is purely about converting the representation graph into a valid YAML string (or vice versa for parsing). Crucially, this stage doesn't handle presentation-specific formatting—it only translates canonical forms into syntax-compliant strings. No display details like date formats or decimal precision are added here.
• Presentation Stage: This is where "formatted content" lives. As explicitly stated in section 3.2.3.2:

  "Like node style, the format is a presentation detail and is not reflected in the serialization tree and representation graph."
  Formatted content is the human-readable version of scalars—think converting an ISO 8601 date to "Jan 1, 2024" or a float to "123.45" instead of its canonical numeric form. It's all about readability, not semantic meaning.

关于图表标注的疑惑 #

Your observation about the spec's figures (3.2, 3.4, 3.5) is spot-on—those +Formatted Content labels are indeed ambiguous, and your proposed adjustment makes perfect sense:

• The Serialization Model should reference Canonical Form, not formatted content. Serialization doesn't introduce presentation details; it just translates the semantic representation into valid YAML syntax.
• The Parse process shouldn't convert formatted content directly to canonical form. Parsing only turns raw YAML strings into a serialization tree—converting that tree to canonical form is the job of the Compose process.
• Formatted content (what you're calling ++Formatted Content) should only appear in the Presentation Model. This is the stage where canonical forms are transformed into human-friendly displays, and these details are optional (not compulsory) as you noted.

总结 #

While it's unlikely the spec has an outright error, the wording and chart labels are definitely imprecise enough to cause confusion. The core takeaway is:

• "Formatted content" is exclusively a presentation-layer concern—it has no impact on data semantics or equality checks.
• The representation layer relies entirely on canonical forms (defined by tags) to ensure semantic consistency.
• Serialization/parsing handle syntax, not presentation; compose/represent handle semantic canonicalization.

Hope this clears things up for you!

备注：内容来源于stack exchange，提问作者the_eraser