Developer tools · Syntax converters
The Norway problem: YAML 1.1 vs 1.2 and why NO becomes false
· Background
yaml data-formats debugging
In YAML 1.1 the unquoted value NO is a boolean, which is how Norway disappears from country lists. This post tells the history of YAML's implicit typing, what the 1.2 specification changed, and why the problem persists in today's tooling.
A list of countries with one missing — NO parsed as false, and a bug report from the Oslo office
The classic bug is an unquoted country code `NO` becoming false. ToolAcre’s tests prove that it does not happen here: both schema options keep `NO`, yes, no, on and off as strings. A story opening with Norway disappearing inside this panel would contradict the implementation.
The example remains useful as a compatibility warning. When another YAML consumer uses legacy rules, ToolAcre’s writer quotes ambiguous strings so downstream readers do not reinterpret them. The reader and writer are configured to prevent the very failure the outline describes.
Norway does not disappear in this converter: NO stays text
This repository documents js-yaml’s restricted JSON and Core schemas and their observed scalar behaviour. It does not contain sources for YAML’s 2001 origins, authors’ intentions or historical design debates. Those claims are omitted rather than reconstructed from memory.
Current mechanism is enough for a practical guide. Plain scalar resolution happens under a selected schema; quoted values remain text; unsupported tags are rejected. Evidence about code should not be stretched into unsourced standards history.
Repository evidence covers current parser configuration, not YAML’s origin history
YAML 1.1 commonly treated yes, no, on and off variants as booleans. That explains why the Norway problem exists in some ecosystems. ToolAcre exposes no 1.1 switch and never demonstrates sexagesimal or legacy octal conversion under such a mode.
Use the hazard to review external parser output, not to predict this panel. If another tool produces false, record its library and schema. ToolAcre’s result can serve as a contrasting YAML 1.2 reading, but not as proof that the other implementation is configured incorrectly for its contract.
Legacy YAML 1.1 booleans explain the hazard but are not enabled here
The strict JSON schema recognizes only JSON-compatible scalar spellings. Core additionally resolves tilde and empty values to null, hexadecimal or `0o` integers, and non-finite numbers. Neither expands the Boolean vocabulary beyond true and false.
Core Infinity and NaN later become null in JSON with warnings because JSON has no representation for them. The difference between schema options is therefore visible and sometimes lossy, even though the Norway value itself stays stable.
Both shipped options are YAML 1.2 schemas
Legacy behaviour survives wherever parser defaults or application conventions retain it. The converter cannot inventory those libraries or versions from repository evidence. Test the actual consumer with a fixture containing ambiguous words and numeric lookalikes.
ToolAcre’s YAML writer adds protective quotes around strings that older readers might type differently, including `NO`, `yes`, `1.0`, `0755` and date-looking text. This compatibility output is measurable and safer than a blanket statement about modern parser adoption.
The hazard survives in other parsers; verify them rather than generalizing from this tool
Convert `countries: [SE, NO, DK]`, `answers: [yes, no, on, off]`, `mode: 0755`, `octal: 0o755`, `version: 1.10` and `empty:`. Under strict, all except JSON-native values remain strings. Under Core, octal becomes 493 and empty becomes null; the country and answer words remain strings.
Quote every token to force text. Then write the JSON result back to YAML and inspect the quotes the serializer chooses. This code-accurate comparison reveals the tool’s rules without pretending to execute a YAML 1.1 mode that does not exist.
Worked example: country codes and scalar lookalikes under the two shipped schemas
Language-specific parser switches, version defaults and framework wrappers are outside this implementation. Their names and behaviour change independently. Consult and test the component that will consume the configuration.
The panel also does not validate application semantics. Keeping `NO` as a string is necessary for a country code, but it cannot prove that `NO` is an allowed value in a specific schema.
Takeaway: quote your strings, know your parser's version — and how converting YAML to JSON in the browser makes implicit typing visible
Quote text that could be retyped, know the schema actually in use and test the consumer. ToolAcre’s two YAML 1.2 options make their limited differences visible and deliberately avoid the legacy Boolean trap.
The lesson is not that every parser behaves one way. It is that implicit typing is configuration, and a converter should state that configuration. Here the evidence says Norway remains `"NO"`.
When configuration crosses systems, add an interoperability fixture containing every ambiguous token your domain permits. Convert or parse it in each real consumer and compare typed values, not rendered YAML. This catches a legacy Boolean table, an octal rule or an empty-value difference before a country list or permission mode reaches production. Quoting known strings remains the simplest portable defence because it records intent in the document rather than relying on environment defaults.