Re: YAML 1.2/1.* vs YAML 2.0
Timothy Hochberg <[email protected]> Thu, 03 Mar 2016 00:00:38 +0000
| Newsgroups | gmane.text.yaml.general |
|---|---|
| Message-ID | <CADwE1D0tH_7QNqiepADx5_gbrwkm7TdF76wjz-aV+B5tZjiEMw@mail.gmail.com> |
On the one hand, I have found composite keys useful on a number of
occasions and I would be annoyed if there wasn't an easy way to spell that
in YAML. However, I'm not sure they would have to be part of the core
syntax. Couldn't they are represented in a similar fashion to the the way
ordered maps are now? Except use a sequence of length 2 sequences rather
than a sequence of length-1 mappings. For instance:
--- !!cmap
-
- [key_1A, key_1B]
- YAML_Value_1
-
- [key_2A, key_2B]
- YAML_Value_2
#...
Where cmap stands for composite map or complex map. (That may not be
correct YAML - I never write YAML by hand these days). That's not
beautiful, but it might be sufficient for serialization applications.
Just a thought,
-tim
On Wed, Mar 2, 2016 at 4:04 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
_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core