I was going to say I have no problem with requiring a final line break.
However... you got me thinking... and I checked json.org.
As I feared, there is no requirement for a final line break in JSON.
So, it seems that for JSON compatibility, we must allow omitting it.
I guess I'll have to fix that. Sigh.
Getting JSON compatibility right turned out to be quite a PITA.
Tweaking b-non-content is an interesting notion...
However it is used in productions 70, 164 and 166 and the effect would be
You'll end up in a case where final line breaks may be omitted if they are
stripped but not if kept, or something along these lines.
It would probably be better to explicitly allow for EOF in the comment
productions (71, 76, 77, 168),
so the final line break would be optional only if it is in a "comment" (or
where a comment is allowed).
I'm in http://linuxfestnorthwest.org/ this weekend so I won't get around to
it until Monday at the earliest.
_Very_ nice catch! Thanks!
On Sat, Apr 25, 2009 at 9:47 AM, Joshua Choi <joshua@...> wrote:
> Addendum: Actually, if b-non-content is changed to:
> b-break | /* End of file */
> ...then perhaps this would be fixed without changing other behavior,
> since this only happens when a stream stops without a trailing break.
> On Sat, Apr 25, 2009 at 9:44 AM, Joshua Choi <joshua@...> wrote:
> > To the YAML 1.2 spec writers,
> > In the current draft, rule #196, s-l+flow-in-block, requires
> > s-l-comments at the end. s-l-comments in turn requires either
> > s-b-comment or the start of the line, and s-b-comment requires
> > b-non-content. The required presence of b-non-content, which is
> > equivalent to b-break, means the following two streams are invalid if
> > they do not end with a break: ...