Re: Possible ambiguity in YAML 1.2 when parsing alias nodes

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