From: Andrey S. <py...@gm...> - 2010-08-18 07:13:09
|
Hi all, according to http://pyyaml.org/wiki/YAMLColonInFlowContext colon in the flow context does not work according to the 1.1 specification in PyYAML. PyYAML follows "pythonic" way instead of implementing language-neutral solution. It causes compatibility issues with other languages. There is an issue reported for SnakeYAML to address the problem - http://code.google.com/p/snakeyaml/issues/detail?id=78 The ticket for PyYAML is created but there is no progress - http://pyyaml.org/ticket/158 I am not really in favor to fix the problem only in SnakeYAML as we find it important that any valid document for SnakeYAML is always valid for PyYAML and vice versa. - Andrey SnakeYAML developer |
From: Kirill S. <xi...@ga...> - 2010-08-24 22:20:40
|
Hi Andrey, On 08/18/2010 03:13 AM, Andrey Somov wrote: > Hi all, > according to http://pyyaml.org/wiki/YAMLColonInFlowContext colon in > the flow context does not work according to the 1.1 specification in > PyYAML. > PyYAML follows "pythonic" way instead of implementing language-neutral > solution. It causes compatibility issues with other languages. > There is an issue reported for SnakeYAML to address the problem - > http://code.google.com/p/snakeyaml/issues/detail?id=78 > > The ticket for PyYAML is created but there is no progress - > http://pyyaml.org/ticket/158 > > I am not really in favor to fix the problem only in SnakeYAML as we > find it important that any valid document for SnakeYAML is always > valid for PyYAML and vice versa. As far as I remember, the YAML 1.1 spec claims that ':' is a valid character for a plain literal if it is not followed by a whitespace, and the mapping separator is ': ' (colon followed by a whitespace). I strongly disagreed with it because it does not follow Python or Javascript conventions, but I didn't want to decide one way or another until some consensus is reached. So I made ':' (colon followed by a non-whitespace character) an error when it is a part of a plain literal in the flow context. I haven't checked the YAML 1.2 specs, but I believe the rules were relaxed to facilitate JSON compatibility. AFAIK, the mapping separator is now ':' (colon), but colon is still a valid character in a plain literal and if it is not followed by a whitespace, it is interpreted as a part of the literal rather than a mapping separator. Thus a JSON expression like {"foo":1} is now a valid YAML. The solution is still not that great since a valid Python or Javascript expression like {1:1} has a different meaning in YAML (in this case, {'1:1': null}). I'm not sure how much this is a problem in practice though. I believe there was another proposal (which I like even less): forbid ':' in mapping keys, but allow them in mapping values. Unfortunately it creates ambiguities in expressions like [foo:bar], which could be interpreted both ways. Note that my understanding of the YAML specs could be incorrect: it was a long time ago since I last read them. Thanks, Kirill |
From: William S. <sp...@rh...> - 2010-08-25 00:53:56
|
libyaml, which I thought was following the spec, quite specifically does not require a ':' in a "flow" context. There is code in there that literally says it is doing this, so somebody thought it was correct. Here is a conversion using the event api of libyaml to read and write some 1-line files (the output has "flow" and all quoting forced on to make it understandable): a:1 -> "a:1" a: 1 -> {"a": "1"} {a:1} -> {"a": "1"} {a: 1} -> {"a": "1"} So libyaml is doing what I think is being requested. Kirill Simonov wrote: > Hi Andrey, > > On 08/18/2010 03:13 AM, Andrey Somov wrote: >> Hi all, >> according to http://pyyaml.org/wiki/YAMLColonInFlowContext colon in >> the flow context does not work according to the 1.1 specification in >> PyYAML. >> PyYAML follows "pythonic" way instead of implementing language-neutral >> solution. It causes compatibility issues with other languages. >> There is an issue reported for SnakeYAML to address the problem - >> http://code.google.com/p/snakeyaml/issues/detail?id=78 >> >> The ticket for PyYAML is created but there is no progress - >> http://pyyaml.org/ticket/158 >> >> I am not really in favor to fix the problem only in SnakeYAML as we >> find it important that any valid document for SnakeYAML is always >> valid for PyYAML and vice versa. |
From: Kirill S. <xi...@ga...> - 2010-08-25 00:47:59
|
Hi William, On 08/24/2010 08:32 PM, William Spitzak wrote: > libyaml, which I thought was following the spec, quite specifically does > not require a ':' in a "flow" context. There is code in there that > literally says it is doing this, so somebody thought it was correct. > > Here is a conversion using the event api of libyaml to read and write > some 1-line files (the output has "flow" and all quoting forced on to > make it understandable): > > a:1 -> "a:1" > a: 1 -> {"a": "1"} > {a:1} -> {"a": "1"} > {a: 1} -> {"a": "1"} > > So libyaml is doing what I think is being requested. Not sure how you get these. The first two examples and the last one are non-controversial. However I'm getting a scanner error on {a:1}: >>> import yaml >>> yaml.load("{a:1}", Loader=yaml.CLoader) Traceback (most recent call last): [...] yaml.scanner.ScannerError: while scanning a plain scalar in "<byte string>", line 1, column 2 found unexpected ':' in "<byte string>", line 1, column 3 Note that CLoader uses libyaml bindings internally. Perhaps you are using some patched version of libyaml? Thanks, Kirill |
From: William S. <sp...@rh...> - 2010-08-25 03:19:21
|
This is the C version of libYAML, looked up in my raw version of the downloaded code from http://pyyaml.org/download/libyaml/yaml-0.1.3.tar.gz The source code file scanner.c contains several examples where it does not require a space after a ':' if inside a "flow" (meaning inside curly or square brackets). "parser->flow_level" is non-zero in this case. The function yaml_parser_fetch_next_token() has this code to see if we are looking at a colon (called a "value indicator"). I am unsure if this code is actually called when using the parser however: /* Is it the value indicator? */ if (CHECK(parser->buffer, ':') && (parser->flow_level || IS_BLANKZ_AT(parser->buffer, 1))) return yaml_parser_fetch_value(parser); The function yaml_parser_scan_plain_scalar() uses the following code to decide if a character ends an unquoted scaler. Besides skipping a test for space after the colon, this also causes the characters ",?[]{}" to end a scaler. I know for a fact that this code is used: /* Check for indicators that may end a plain scalar. */ if ((CHECK(parser->buffer, ':') && IS_BLANKZ_AT(parser->buffer, 1)) || (parser->flow_level && (CHECK(parser->buffer, ',') || CHECK(parser->buffer, ':') || CHECK(parser->buffer, '?') || CHECK(parser->buffer, '[') || CHECK(parser->buffer, ']') || CHECK(parser->buffer, '{') || CHECK(parser->buffer, '}')))) break; Kirill Simonov wrote: > Hi William, > > On 08/24/2010 08:32 PM, William Spitzak wrote: >> libyaml, which I thought was following the spec, quite specifically does >> not require a ':' in a "flow" context. There is code in there that >> literally says it is doing this, so somebody thought it was correct. >> >> Here is a conversion using the event api of libyaml to read and write >> some 1-line files (the output has "flow" and all quoting forced on to >> make it understandable): >> >> a:1 -> "a:1" >> a: 1 -> {"a": "1"} >> {a:1} -> {"a": "1"} >> {a: 1} -> {"a": "1"} >> >> So libyaml is doing what I think is being requested. > > Not sure how you get these. The first two examples and the last one are > non-controversial. However I'm getting a scanner error on {a:1}: > > >>> import yaml > >>> yaml.load("{a:1}", Loader=yaml.CLoader) > Traceback (most recent call last): > [...] > yaml.scanner.ScannerError: while scanning a plain scalar > in "<byte string>", line 1, column 2 > found unexpected ':' > in "<byte string>", line 1, column 3 > > Note that CLoader uses libyaml bindings internally. > > Perhaps you are using some patched version of libyaml? > > > Thanks, > Kirill |
From: Kirill S. <xi...@ga...> - 2010-08-25 04:35:40
|
Hi William, If you take a look at the function yaml_parser_scan_plain_scalar, lines 3424-3433, you'll see: /* Check for 'x:x' in the flow context. TODO: Fix the test "spec-08-13". */ if (parser->flow_level && CHECK(parser->buffer, ':') && !IS_BLANKZ_AT(parser->buffer, 1)) { yaml_parser_set_scanner_error(parser, "while scanning a plain scalar", start_mark, "found unexpected ':'"); goto error; } This condition is only checked in the flow context and it produces an error if there is a colon followed by a non-whitespace character. Therefore it should produce an error for {a:1} and I don't understand how you could get {"a": "1"}. The YAML spec (1.1 and I suppose 1.2 too) interprets {a:1} as {"a:1": null}. Thanks, Kirill On 08/24/2010 11:19 PM, William Spitzak wrote: > This is the C version of libYAML, looked up in my raw version of the > downloaded code from http://pyyaml.org/download/libyaml/yaml-0.1.3.tar.gz > > The source code file scanner.c contains several examples where it does > not require a space after a ':' if inside a "flow" (meaning inside curly > or square brackets). "parser->flow_level" is non-zero in this case. > > The function yaml_parser_fetch_next_token() has this code to see if we > are looking at a colon (called a "value indicator"). I am unsure if this > code is actually called when using the parser however: > > /* Is it the value indicator? */ > > if (CHECK(parser->buffer, ':') > && (parser->flow_level || IS_BLANKZ_AT(parser->buffer, 1))) > return yaml_parser_fetch_value(parser); > > The function yaml_parser_scan_plain_scalar() uses the following code to > decide if a character ends an unquoted scaler. Besides skipping a test > for space after the colon, this also causes the characters ",?[]{}" to > end a scaler. I know for a fact that this code is used: > > /* Check for indicators that may end a plain scalar. */ > > if ((CHECK(parser->buffer, ':') && IS_BLANKZ_AT(parser->buffer, 1)) > || (parser->flow_level && > (CHECK(parser->buffer, ',') || CHECK(parser->buffer, ':') > || CHECK(parser->buffer, '?') || CHECK(parser->buffer, '[') > || CHECK(parser->buffer, ']') || CHECK(parser->buffer, '{') > || CHECK(parser->buffer, '}')))) > break; > > > Kirill Simonov wrote: >> Hi William, >> >> On 08/24/2010 08:32 PM, William Spitzak wrote: >>> libyaml, which I thought was following the spec, quite specifically does >>> not require a ':' in a "flow" context. There is code in there that >>> literally says it is doing this, so somebody thought it was correct. >>> >>> Here is a conversion using the event api of libyaml to read and write >>> some 1-line files (the output has "flow" and all quoting forced on to >>> make it understandable): >>> >>> a:1 -> "a:1" >>> a: 1 -> {"a": "1"} >>> {a:1} -> {"a": "1"} >>> {a: 1} -> {"a": "1"} >>> >>> So libyaml is doing what I think is being requested. >> >> Not sure how you get these. The first two examples and the last one >> are non-controversial. However I'm getting a scanner error on {a:1}: >> >> >>> import yaml >> >>> yaml.load("{a:1}", Loader=yaml.CLoader) >> Traceback (most recent call last): >> [...] >> yaml.scanner.ScannerError: while scanning a plain scalar >> in "<byte string>", line 1, column 2 >> found unexpected ':' >> in "<byte string>", line 1, column 3 >> >> Note that CLoader uses libyaml bindings internally. >> >> Perhaps you are using some patched version of libyaml? >> >> >> Thanks, >> Kirill |
From: William S. <sp...@rh...> - 2010-08-25 20:11:32
|
Kirill Simonov wrote: > Hi William, > > If you take a look at the function yaml_parser_scan_plain_scalar, lines > 3424-3433, you'll see: > > /* Check for 'x:x' in the flow context. TODO: Fix the test "spec-08-13". */ > > if (parser->flow_level > && CHECK(parser->buffer, ':') > && !IS_BLANKZ_AT(parser->buffer, 1)) { > yaml_parser_set_scanner_error(parser, "while scanning a plain scalar", > start_mark, "found unexpected ':'"); > goto error; > } > > This condition is only checked in the flow context and it produces an > error if there is a colon followed by a non-whitespace character. You are right, my compiled version has that line commented out, as I had to fix it to read some JSON text. My personal opinion is that this MUST be changed. I had to fix it to read JSON output and I can't be the only one. There are VAST amounts of "unquoted" JSON out there, probably the majority! If YAML has any intention of being JSON-compatible it must fix this. I have unfortunatly drifted away from YAML. I am using my patched version of the parser, but am not using any code for emitting it. Instead I wrote a much faster one which outputs YAML with "flow" turned on all the time, and with the ability to put newlines between the "flow" items. I quote everything containing any characters other than alphanumeric, period, underscore, +, or -. I am increasingly of the belief that a correct format would be more like JSON with optional quoting, with the addition of "type" and the addition of cross-references. Currently I am persuing this, though I am following the YAML discussion in case something interesting comes up. |
From: Kirill S. <xi...@ga...> - 2010-08-25 20:53:38
|
On 08/25/2010 04:11 PM, William Spitzak wrote: > Kirill Simonov wrote: >> Hi William, >> >> If you take a look at the function yaml_parser_scan_plain_scalar, lines >> 3424-3433, you'll see: >> >> /* Check for 'x:x' in the flow context. TODO: Fix the test "spec-08-13". */ >> >> if (parser->flow_level >> && CHECK(parser->buffer, ':') >> && !IS_BLANKZ_AT(parser->buffer, 1)) { >> yaml_parser_set_scanner_error(parser, "while scanning a plain scalar", >> start_mark, "found unexpected ':'"); >> goto error; >> } >> >> This condition is only checked in the flow context and it produces an >> error if there is a colon followed by a non-whitespace character. > > You are right, my compiled version has that line commented out, as I had > to fix it to read some JSON text. My personal opinion is that this MUST > be changed. I had to fix it to read JSON output and I can't be the only > one. There are VAST amounts of "unquoted" JSON out there, probably the > majority! If YAML has any intention of being JSON-compatible it must fix > this. By unquoted JSON, do you mean something like: {foo:"bar"} This is definitely not a valid JSON and I'm certain most of the JSON parsers will fail to parse it. I'd say that an ability to parse this expression has nothing to do with JSON-compatibility, though you could claim it is Javascript-compatibility. I believe both YAML 1.1 and 1.2 interpret this document as {'foo:"bar"': null} PyYAML and libyaml producing an error is a stub; I intended to replace it with one interpretation or the other once I make up my mind. Producing an error allows me to choose the interpretation without breaking existing valid YAML documents. > I have unfortunatly drifted away from YAML. I am using my patched > version of the parser, but am not using any code for emitting it. > Instead I wrote a much faster one which outputs YAML with "flow" turned > on all the time, and with the ability to put newlines between the "flow" > items. I quote everything containing any characters other than > alphanumeric, period, underscore, +, or -. > > I am increasingly of the belief that a correct format would be more like > JSON with optional quoting, with the addition of "type" and the addition > of cross-references. Currently I am persuing this, though I am following > the YAML discussion in case something interesting comes up. Well, YAML is JSON with optional quoting, types, cross-references, and also block styles. Thanks, Kirill |
From: William S. <sp...@rh...> - 2010-08-26 02:13:17
|
Kirill Simonov wrote: > By unquoted JSON, do you mean something like: > {foo:"bar"} Yes, though {foo: "bar"} is probably a better example (note the space!) > This is definitely not a valid JSON and I'm certain most of the JSON > parsers will fail to parse it. However there are a lot of pseudo-JSON parsers that *do* parse it, including libyaml itself! The problem is that except for libyaml, every single parser I know of that can read the version with the space will also read the version without the space. This is a very rude suprise to users who will logically think that yaml reads a superset of some definition they are familiar with. It can "sort of" read unquoted JSON, but not all the files. At least the current version produced an error, so the user knows something went wrong (although I had to pretty quickly patch it and remove the test because I encountered so many files that would not read). But if you change it to silently produce unexpected results I think it will be a disaster! If the concern is for typing url data in, I would just change the rules for colon for an unquoted scaler depending on whether a key or value is being read in. You could even allow following spaces. The following: {foo:http:baz: zoo} would be interpreted as: {"foo" : "http:baz: zoo") It would seem that such a design is much more in keeping with the style of YAML. |
From: Kirill S. <xi...@ga...> - 2010-08-26 03:01:30
|
On 08/25/2010 10:12 PM, William Spitzak wrote: > Kirill Simonov wrote: > >> By unquoted JSON, do you mean something like: >> {foo:"bar"} > > Yes, though > {foo: "bar"} > is probably a better example (note the space!) > >> This is definitely not a valid JSON and I'm certain most of the JSON >> parsers will fail to parse it. > > However there are a lot of pseudo-JSON parsers that *do* parse it, > including libyaml itself! A lot? Other than Javascript eval(), I'm not aware of any parser library that could parse it. Python's standard json.py module certainly cannot do it. Could you name some of the parsers, please? > > If the concern is for typing url data in, I would just change the rules > for colon for an unquoted scaler depending on whether a key or value is > being read in. You could even allow following spaces. The following: > > {foo:http:baz: zoo} > > would be interpreted as: > > {"foo" : "http:baz: zoo") > > It would seem that such a design is much more in keeping with the style > of YAML. I see two problems with this definition. First, it complicates the YAML grammar even further by creating 3 similar, but subtly different plain scalar styles. The YAML grammar is already complex enough, I'd prefer not to have it even more complex. Second, it creates an ambiguity in the case: [foo:bar] (or even [foo: bar]) which could be interpreted as ["foo:bar"] or as [{"foo": "bar"}] depending on whether you consider `foo: bar` a single value or a key: value pair. Thanks, Kirill |
From: William S. <sp...@rh...> - 2010-08-26 03:29:32
|
Kirill Simonov wrote: > On 08/25/2010 10:12 PM, William Spitzak wrote: >> Kirill Simonov wrote: >> >>> By unquoted JSON, do you mean something like: >>> {foo:"bar"} >> >> Yes, though >> {foo: "bar"} >> is probably a better example (note the space!) >> >>> This is definitely not a valid JSON and I'm certain most of the JSON >>> parsers will fail to parse it. >> >> However there are a lot of pseudo-JSON parsers that *do* parse it, >> including libyaml itself! > > A lot? Other than Javascript eval(), I'm not aware of any parser library > that could parse it. Python's standard json.py module certainly cannot > do it. Could you name some of the parsers, please? libyaml! >> {foo:http:baz: zoo} >> >> would be interpreted as: >> >> {"foo" : "http:baz: zoo") > > I see two problems with this definition. > > First, it complicates the YAML grammar even further by creating 3 > similar, but subtly different plain scalar styles. The YAML grammar is > already complex enough, I'd prefer not to have it even more complex. Fair enough. > Second, it creates an ambiguity in the case: > [foo:bar] (or even [foo: bar]) > which could be interpreted as > ["foo:bar"] > or as > [{"foo": "bar"}] > depending on whether you consider `foo: bar` a single value or a key: > value pair. A quick check shows that libyaml already accepts [foo: bar] and interprets it as [{"foo": "bar"}] so this problem already exists and my change would do nothing to make this harder or easier. |
From: Kirill S. <xi...@ga...> - 2010-08-26 03:47:10
|
On 08/25/2010 11:29 PM, William Spitzak wrote: > Kirill Simonov wrote: >> On 08/25/2010 10:12 PM, William Spitzak wrote: >>> Kirill Simonov wrote: >>> >>>> By unquoted JSON, do you mean something like: >>>> {foo:"bar"} >>> >>> Yes, though >>> {foo: "bar"} >>> is probably a better example (note the space!) >>> >>>> This is definitely not a valid JSON and I'm certain most of the JSON >>>> parsers will fail to parse it. >>> >>> However there are a lot of pseudo-JSON parsers that *do* parse it, >>> including libyaml itself! >> >> A lot? Other than Javascript eval(), I'm not aware of any parser library >> that could parse it. Python's standard json.py module certainly cannot >> do it. Could you name some of the parsers, please? > > libyaml! And that's it? Hardly a lot. > >>> {foo:http:baz: zoo} >>> >>> would be interpreted as: >>> >>> {"foo" : "http:baz: zoo") > > >> I see two problems with this definition. >> >> First, it complicates the YAML grammar even further by creating 3 >> similar, but subtly different plain scalar styles. The YAML grammar is >> already complex enough, I'd prefer not to have it even more complex. > > Fair enough. > >> Second, it creates an ambiguity in the case: >> [foo:bar] (or even [foo: bar]) >> which could be interpreted as >> ["foo:bar"] >> or as >> [{"foo": "bar"}] >> depending on whether you consider `foo: bar` a single value or a key: >> value pair. > > A quick check shows that libyaml already accepts [foo: bar] and > interprets it as [{"foo": "bar"}] so this problem already exists and my > change would do nothing to make this harder or easier. The problem is that according to your proposal, this should be interpreted as ["foo: bar"] instead. Thanks, Kirill |
From: Andrey S. <py...@gm...> - 2010-08-25 08:03:13
|
I still do not understand why we do not follow the spec: 1) {a:1} -> {"a:1": null} (yes, it is not intuitive, but according to the spec) 2) {url: http://dot.com} -> "url": "http://dot.com" I think it is better to implement p.1 instead of the current failure because we can give a chance to a user to fix the problem at runtime. >I strongly disagreed with it because it does not follow Python or Javascript conventions, >but I didn't want to decide one way or another until some consensus is reached. >So I made ':' (colon followed by a non-whitespace character) an error when it is a part of a plain literal in the flow context. People agree on the specification exactly to avoid personal flavors. For instance I totally disagree to have 18 (!!!) possible alternatives for a boolean value but nevertheless I had to implement them all. SnakeYAML does not fail on 'Yes'. (even though I am sure it should be just !!str) Since 1.2 specification did not make any change about a colon on the flow context I feel it is better to follow the spec. I think that this is the indication that the consensus is reached. -Andrey |
From: Kirill S. <xi...@ga...> - 2010-08-25 14:59:01
|
On 08/25/2010 04:03 AM, Andrey Somov wrote: > I still do not understand why we do not follow the spec: > > 1) {a:1} -> {"a:1": null} (yes, it is not intuitive, but according to the spec) > 2) {url: http://dot.com} -> "url": "http://dot.com" > > I think it is better to implement p.1 instead of the current failure > because we can give a chance to a user to fix the problem at runtime. > > >> I strongly disagreed with it because it does not follow Python or Javascript conventions, >> but I didn't want to decide one way or another until some consensus is reached. >> So I made ':' (colon followed by a non-whitespace character) an error when it is a part of a plain literal in the flow context. > > People agree on the specification exactly to avoid personal flavors. I just treated these issues as bugs in the spec. > For instance I totally disagree to have 18 (!!!) possible alternatives > for a boolean value but nevertheless I had to implement them all. > SnakeYAML does not fail on 'Yes'. (even though I am sure it should be > just !!str) Yet you may notice that YAML 1.2 spec reduced them to: true | True | TRUE | false | False | FALSE And now we have a problem with compatibility: how could we move to 1.2 without breaking user's YAML data. Had we followed the common sense in this case, it would be much better for everyone. > Since 1.2 specification did not make any change about a colon on the > flow context I feel it is better to follow the spec. I think that this > is the indication that the consensus is reached. You are wrong about the 1.2 spec not changing interpretation of a colon in the flow context; it is now much closer to what PyYAML does, and exactly for the same reasons: compatibility. In 1.1: {"a":"b"} -> error In 1.2 (and PyYAML): {"a":"b"} -> {"a": "b"} Thanks, Kirill |
From: Andrey S. <py...@gm...> - 2010-08-26 08:37:27
|
Thank you for the clarification. I agree with Kirill. My conclusion is: SnakeYAML will keep the status quo. Any success of failure will stay identical for both PyYAML and SnakeYAML. P.S. I am looking forward to see PyYAML implementing the latest 1.2 specification... - Andrey |
From: William S. <sp...@rh...> - 2010-08-26 18:49:57
|
I am altering our own output to put spaces after the colons to remain compatible with YAML (though the parser necessarily will have to handle colons without spaces). I am quite happy that YAML does not require quotes around all the strings and did not want to sound hostile. I still think it is illogical that it provides this convienent aspect that many other JSON parsers do while not providing the no-space-after-colon feature that all such JSON parsers do as well. |
From: William S. <sp...@rh...> - 2010-08-26 04:12:55
|
Kirill Simonov wrote: >>> A lot? Other than Javascript eval(), I'm not aware of any parser library >>> that could parse it. Python's standard json.py module certainly cannot >>> do it. Could you name some of the parsers, please? >> libyaml! > > And that's it? Hardly a lot. Well the obvious thing is that javascript syntax does not require it. A JSON derivative called Rison does not require it either and strips quotes from keys on output. That was found 5 entries down on the first page of a Google search. I'm sure there are more. Also found a lot of bitching about parsers that require the quotes. >> A quick check shows that libyaml already accepts [foo: bar] and >> interprets it as [{"foo": "bar"}] so this problem already exists and my >> change would do nothing to make this harder or easier. > > The problem is that according to your proposal, this should be > interpreted as ["foo: bar"] instead. I would certainly consider that a much better result than what YAML is doing right now! Although throwing a parse error might be ok as well. The current behavior is bizzare and certainly unexpected! |