In Working Draft 2008-05-11, production 208 references ns-l+block-node, which isn’t defined.   Instead production 197 defines s-l+block-node which I think might be what’s intended.   I’m not sure what the correct name is, but it looks like a typo in one place or the other.

 

Also regarding the production naming, I’d suggest it might make sense to distinguish between simple character-class productions (with a c- prefix), from the more complex indicator-based productions (with perhaps a i- prefix).   For example, I’d rename c-ns-tag-property to i-tag-property, c-single-quoted to i-single-quoted, c-flow-sequence to i-flow-sequence, etc.     This obviously doesn’t impact the validity of the document, but I believe it would improve its understandability.  

 

I’m not sure what motivated the change from V1.1’s  c-l-block-sequence to V1.2’s l-block-sequence; whatever the reason, I applaud it!  I think reducing the number of productions that start with a comment or non-indent whitespace will make it much easier to map the spec. to practical implementations.   Perhaps some simpler Hungarian prefix for block constructs like s-l+block-indented would help.  I’m not sure how to put this in parser terminology, but after having struggled with 1.1s productions for quite a while, it seems like a good idea.   It would be incredibly useful to be able to express YAML’s syntax with the same sort of railroad track diagrams that JSONs is documented in.