[Yaml-core] Seperation Spaces

[Oren Ben-K. <or...@be...>]

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:

	---
	flow value:
	    !str
	      &anchor
	 "text"
	...

But this isn't:

	---
	block value:
	  !str
	    &anchor
	      |
	 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:
	  !clarkevans.com,2002/commercial/invoice
	  &invoice12345
	    total: ...
	...

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 
context.

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:

	<SOF>
	!seq
	- entry
	<EOF>

Is equivalent to:

	<SOF>
	--- %YAML:1.0
	!seq
	- entry
	<EOF>

Which would now be valid. This simplifies the rules (and, of course, the 
productions).

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.

Thoughts?

Have fun,

	Oren Ben-Kiki

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 :-)