Re: Possible ambiguity in YAML 1.2 when parsing alias nodes
Ingy dot Net <[email protected]> Sun, 6 Mar 2016 08:21:04 -0800
| Newsgroups | gmane.text.yaml.general |
|---|---|
| Message-ID | <CAHJtQJ5jkupQyJiOY_4EKk98WepiJ8QkE2+Ayr=zcjw7pjg5tg@mail.gmail.com> |
Felix, Make sure this ends up in the test suite. I still owe you documentation on the test suite layouts and formats. Since the tests have tags, one thing we can do is add tests for ideas that we want in 1.3 or 2.0 and tag them as such. That will allow us to have more precise discussions and also to build strawman parsers/processors for possible future YAMLs. On Sat, Mar 5, 2016 at 10:36 AM, Oren Ben-Kiki <[email protected]> wrote: > Interesting. > > YamlReference parses it - http://ben-kiki.org/ypaste/data/9/index.html - > and this is "deterministic" based on the pattern matching being "greedy". > > That said, I'm not certain this is the "right thing to do", that is, > should people that: > - &a foo > - *a: bar > Would work? Right now, it doesn't: > http://ben-kiki.org/ypaste/data/10/index.html - you need to write: > - &a foo > - *a : bar > Which does work: http://ben-kiki.org/ypaste/data/11/index.html > > We had a back-and-forth about allowed characters in an anchor, starting > with "only identifiers" - letters, digits, etc. - which was deemed to be > too restrictive. We then loosened it - it seems, too much. The safe thing > to do would be to disallow any c-indicator character inside an anchor, I > guess. > > Sigh. At least the current spec is deterministic (assuming greediness). > The above is something we _may_ want to change in a 2.0 (or even 1.3). > > Nice catch. > > Oren. > > On Sat, Mar 5, 2016 at 12:44 PM, flyx <[email protected]> wrote: > >> Hi folks, >> >> while implementing NimYAML, I found the following ambiguity in the spec: >> >> &a: key: &a value >> foo: >> *a: >> >> Firstly, ':' is allowed inside an anchor name, because it is not a >> c-flow-indicator, so this input is valid. But the last line is >> ambiguous. I can parse it as: >> >> s-l+block-node(n,c) -> >> s-l+block-in-block(n,c) -> >> s-l+block-collection(n,c) -> >> l+block-mapping(n) -> >> ns-l-block-map-entry(n) -> >> ns-l-block-map-implicit-entry(n) -> >> ns-s-block-map-implicit-key c-l-block-map-implicit-value(n) -> >> ns-s-implicit-yaml-key(c) ":" e-node s-l-comments -> >> ns-flow-yaml-node(n,c) ":" "" "" -> >> c-ns-alias-node ":" -> >> "*" ns-anchor-name ":" -> >> "*a" ":" -> >> "*a:" >> >> But this is also possible: >> >> s-l+block-node(n,c) -> >> s-l+flow-in-block(n) -> >> ns-flow-node(n+1,flow-out) s-l-comments -> >> c-ns-alias-node "" -> >> "*" ns-anchor-name -> >> "*a:" >> >> So the node can be either parsed as a map with one entry having "*a" as >> key and an empty scalar as value, or as a single alias node "*a:". This >> is possible because in >> >> ns-s-implicit-yaml-key(c) ::= ns-flow-yaml-node(n/a,c) >> s-separate-in-line? >> >> the s-separate-in-line is optional. Interestingly, a simple "&a:" is not >> ambiguous, because the properties must be separate from the scalar >> content, even if it is empty. So in order to parse that as implicit key, >> it must be written as "&a :". >> >> Am I overlooking something? >> >> Cheers, >> Felix >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Yaml-core mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/yaml-core >> > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Yaml-core mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/yaml-core > > ------------------------------------------------------------------------------ _______________________________________________ Yaml-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/yaml-core