Re: Possible ambiguity in YAML 1.2 when parsing alias nodes

Felix,

YAML specification solves the ambiguity by always
taking the first option when an input can be reduced
by several alternative rules. That's what Oren wanted
to mention although greediness did not seem to be the
best word to describe it.

It is mentioned in the YAML1.2 spec in Chap 4 as:

> The order of alternatives inside a production is
>significant. Subsequent alternatives are only
>considered when previous ones fails.

Best,
Osamu Takeuchi


On 2016/03/06 3:36, Oren Ben-Kiki 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] <mailto:[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] <mailto:[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