Do the productions in the YAML 1.2 spec allow spaces in plain scalars?

[GrahamHannington]

In brief

As far as I can tell, the answer is "No".

Either:

(a) I'm missing something

or

(b) There's a problem with the productions

I'm inclined to think it's (a). I think it's much more likely that I'm not correctly interpreting the productions.

Still, if it's (a): what am I missing? Could someone please quote the specific snippet of a production in the YAML 1.2 spec that allows spaces in a plain scalar? I can't find it.

In detail

The YAML 1.1 and 1.2 specs both contain numerous examples of spaces in plain scalars.

For example, the space between Mark and McGwire:

name: Mark McGwire

I can see how the productions for plain scalars in the YAML 1.1 spec allow spaces: those productions are based on nb-char, which includes the space character.

However, all the productions for plain scalars in the YAML 1.2 spec (not just the first character) are based on ns-char, which excludes the space character.

Here, in this issue, I'm specifically asking about what the productions in the YAML 1.2 spec allow, not what implementations allow.

[Thom1729]

See:

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

This is included in ns-plain via the following paths:

• ns-plain(n,FLOW-OUT or FLOW-IN) → ns-plain-multi-line → ns-plain-one-line → nb-ns-plain-in-line
• ns-plain(n,FLOW-OUT or FLOW-IN) → ns-plain-multi-line → s-ns-plain-next-line → nb-ns-plain-in-line
• ns-plain(n,BLOCK-KEY or FLOW-KEY) → ns-plain-one-line → nb-ns-plain-in-line

[GrahamHannington]

👍 Thank you! Especially, for those paths; that really helps.

In future, I'll take more time to interpret the productions and their relationships.

I confess that, while I've had some exposure to BNF in other contexts, I'm not yet at ease with the parameterized productions in the YAML spec, and I'm finding them a little difficult to follow. My problem; I'll get there. I acknowledge and appreciate the more detailed descriptions of these productions in the YAML 1.2 spec compared to the YAML 1.1 spec. (YAML blog: "The parameterized BNF used by the spec is now fully documented".)

My embarrassment is outweighed by being happy and grateful to have learned something. Thanks again. 🙂

[GrahamHannington]

Cringe, sorry: I closed this issue as "Complete" without thinking too hard about it. Maybe "Not planned" would have been better.
"User error" would be even more accurate. Please feel free to change the reason or ask me to do it.

[Thom1729]

I'm not yet at ease with the parameterized productions in the YAML spec, and I'm finding them a little difficult to follow.

Feedback is appreciated. I basically just kind of made up the parameterization formalism, loosely inspired by the ECMAScript spec (which only has to deal with finitely many cases). I think it's fundamentally sound, but there's surely room for improvement. I mean, I straight-up forgot to define the difference operator (#293). I'm just happy that it's sufficiently well-defined that people can nitpick it.

A minor point, but the grammar more closely resembles a Parsing Expression Grammar than it does BNF. The chief difference is that in a PEG, alternation (and other operators) is ordered, so if (A | B) matches A, then it does not match B. This means that the grammar is never ambiguous (though this actually causes a really obscure theoretical bug involving block collection node properties that I think I documented somewhere). In BNF, a grammar can be ambiguous, which is generally bad. It's always possible to write an unambiguous BNF grammar, but not necessarily easy to prove that a grammar is unambiguous. In a perfect world, it would be nice if the YAML grammar functioned unambiguously as BNF as well as as a PEG.