Re: YAML 1.2/1.* vs YAML 2.0

On 3/3/16, Andrey Somov <[email protected]> wrote:
> Well,
> I wish that:
>
> - "docker inspect" gives YAML output
> - "git log" gives YAML output (so I can easily parse it if I want)
> - "git config" uses YAML
> - Mercurial's .hgignore file is using YAML
> - YAML is the first choice to export data from MS Excel
> - YAML is the first choice to provide tests data (testers always complain
> about unreadable data structures)

Fantastic goals! I too want to see these things. Let's refine the
"gives YAML output" bit to "gives very nice human editable YAML
output" - the goal in these examples you suggest, should be nothing
less.


> - YAML becomes so ubiquitous that every tool gives a way to import data in
> YAML format

Data import is an interesting thing/ field/ problem. Once a tool is
saving/ exporting YAML, then it is trivial to re-import its own
exported data, but I think you're referring to something slightly
different here - cross-application compatibility. "Ubiquity of YAML"
is I think a great goal - yes, let's replace XML, perhaps someone can
produce a blog page of pros and cons as to why that's a superb idea
and ought be a goal for the entire computing world.

Databases have whole/large applications for facilitate data export,
processing and import - ETL, extract, trasform, load. It's a field you
might want to look at, to get a feel for the kinds of problems they
face. I'm sure the LibreOffice guys have war stories in their MSOffice
file format compatibility libraries too.


> The direction is (human is actively involved):
> - configuration
> - visual data representation

I might add, or re-word your last one:
- human enjoyable data serialization format

This is how I use YAML. This is -why- I use YAML. This is why I never
even "learned how to use" JSON - the damn thing's an ugly duckling,
despite being "better than XML" (what a goal to strive for, "better
than XML") - and JSON seems deficient to me anyway.

YAML, now we're talking :)

> If the goal is to serve as serialisation format (human is passively
> involved), then there is no need for a new specification.

I guess the YAML 1.x series makes sense for "backwards compatible",
iff there is to be a not backwards compatible version.


Back to YAML ubiquity - it is partly an awareness, advocacy and
education problem. There may be some barriers on the parser
programmers side. There may be room for a simplified YAML.

Good luck,
Zenaan

------------------------------------------------------------------------------
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