Re: YAML 1.2/1.* vs YAML 2.0

Personally I would like to see the rules simplified for:
- when whitespace after a key-value separator colon is mandatory
- when unescaped newline characters are permitted in a quoted scalar

I understand why these things shaped up the way they did, to balance
JSON compatibility with back-compatibility, but I agree
back-compatibility should not be a high priority going forward.

For anyone who's not sure what I'm talking about here: without
checking the spec or trying a parser, do you know with certainty which
of the following are valid flow-style maps?

--- #1
{key:value}
--- #2
{key:}
--- #3
{?key:value}
--- #4
{"key":"value"}
--- #5
{?"key":"value"}
--- #6
{"key":"one
           two"}
--- #7
{"one
  two":"value"}
--- #8
{?"one
    two":"value"}

On Wed, Mar 2, 2016 at 11:03 PM, Andrey Somov <[email protected]> wrote:
> Hi all,
> (I think my request to drop complex keys requires first to clarify what we
> discuss)
>
> 1) YAML 2.0 will not be backwards compatible
> 2) YAML 2.0 is the recognition that a lot of things should be radically
> improved
> 3) If you are happy using 1.1 - no problem. It will not disappear
> (if you use YAML alone and do not exchange documents - nothing to worry
> about)
> 4) YAML2 is the code name for an effort to _revitalize_ the YAML
> serialization language.
> 5) Good Parts stay (https://github.com/yaml/YAML2/wiki/Good-Parts)
>
> Now my personal vision:
> a) the more is thrown away - the better.
> b) since the complex key adds complexity and reduces readability - it should
> be removed
> c) any other counter-intuitive feature should be removed (for instance 18
> values for boolean)
> d) any feature which adds to "Good parts" should stay, for instance literal
> block scalars (because they improve readability).
> e) the specification should be small and simple enough to be read and
> understood within half of a day. If a young developer cannot get the spec,
> it will be thrown away (this is what happens now)
> (Those who like to read prefer "War and Peace")
>
> My proposal: remove everything except "good parts" and add only those which
> get enough support from the community. (if the complex keys are really
> helpful they should stay)
>
> Cheers,
> Andrey
>
>
> P.S. JSON is younger then XML and YAML. JSON is far simpler than both.
> JSON has less versions than both. JSON has far less features and
> possibilities.
>
> JSON's unique feature - it is simple and uniform.
>
> Build a better mousetrap, and the world will beat a path to your door
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Yaml-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/yaml-core
>

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140