ns-l+block-node vs. s-l+block node in working draft
Burt Harris <[email protected]>
| Newsgroups | gmane.text.yaml.general |
|---|---|
| Message-ID | <4367B3F0BD5AA84DBE0A9DA5AAF7B7B95635280DD3@NA-EXMSG-C103.redmond.corp.microsoft.com> |
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. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Yaml-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/yaml-core