I'm in the process of going over all the productions and writing annotated
examples (marking up which part of the text matches the demonstrated
production). It is amazing how many subtle issues surface when you do that...
For example, seperation spaces. Currently, this is valid:
But this isn't:
This literal is indented
by a single space.
Technically (production-wise), there's a "seperation-spaces" production that
is currently limited to a single line in block context but not in flow
context. There's really no good reason for this, but I don't recall that we
ever discussed this.
Is it useful? Well, being able to wrap long lines is useful for better
presentation. For example:
the customer's invoice:
Is it a parsing problem? Not really. A parser needs to handle next-line node
properties anyway, for flow values.
Proposal 1: Relax the seperation spaces to allow line-spanning in block
This goes back to the implicit header issue. Brian suggested:
> The absence of a header should be taken to imply a header that looks
> exactly like this:
> --- %YAML:1.0
Now, assume we limit directives to a single line, (reasonable since we are
discouraging their use). Since we allow next-line node properties in block
mode, it means that:
Is equivalent to:
Which would now be valid. This simplifies the rules (and, of course, the
Proposal 2: Use Brian's "implicit header" rule combined with proposal 1, to
allow properties without a header (directives do require a header because
they must be in the same line with it).
In fact, if we just use Brian's implicit header rule, we could trivially allow
header-less top-level scalar nodes. That would further simplify the rule (and
the productions :-)
Proposal 3: Proposal 2, plus removing the (now arbitrary) restrictions that
top-level nodes may not be scalars.
P.S. Working the examples, I think we'll have to modify the block line folding
rules a tiny bit - but that's a seperate posting :-)