Re: YAML 1.2/1.* vs YAML 2.0

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)
- YAML becomes so ubiquitous that every tool gives a way to import data in
YAML format

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

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

Cheers,
Andrey





On Thu, Mar 3, 2016 at 6:51 AM, Oren Ben-Kiki <[email protected]> wrote:

> On Thu, Mar 3, 2016 at 6:21 AM, Peter Murphy <[email protected]>
> wrote:
>
>> As I observe, the problems that people have is with the multiplicity
>> of ways to present the same information, and the issues some of those
>> ways have.
>
>
> +1. Note that some of the examples (such as the boolean problem) is due to
> people using YAML1.1 and ignoring the pretty explicit YAML1.2
> failsafe/JSON-compatible/"Core" schema spec. A "Core"-schema YAML1.2 parser
> does not have this specific problem. But some problems (such as the folded
> blocks) remain.
>
>  The removal of composite keys requires a change to the YAML _content
>
>> model_, on the other hand, and so it becomes impossible to represent
>> the same thing that used to be representable in YAML.
>
>
> +1 again. IMVHO we will not drop composite keys. If you don't want them,
> don't use them. If your application doesn't support them, reject inputs
> that use them. But they are there for those who do need them and I don't
> see them going away.
>
> IMO YAML2.0 w/o composite keys isn't YAML2.0, it is JSON2.0. If that's
> what people need - great! there have been several attempts to move the JSON
> spec forward, and doing so while keeping YAML compatibility in mind would
> be nice; we should ensure that YAML2.0 would be a superset of JSON2.0 - if
> there is such a thing.
>
> In 10 years, we basically didn't hear any request for truly new features,
> which I take to mean that the basic design is good - especially the data
> model. I don't want to touch that part. We did get a lot of complaints
> about the difficulty of parsing, and people just didn't use some of the
> stuff (folded blocks, %TAG, ...).
>
> So the way I see it, YAML2.0 should be basically YAML1.2 minus the stuff
> that people turned out not to use in the past 10 years, with the goal of
> making parsing as simple as we can make it. I'd like to spend some time on
> figuring out how to make the spec friendly for parser generators, for
> example. The main problem is the pesky indentation rules. Maybe we can do
> something about that.
>
> I very much like Ingy's proposal of replacing folded blocks with something
> based on ".
>
> I think lots of people use | blocks though (I certainly do) so I'd be
> careful modifying that. I like the idea of dropping the explicit
> indentation integer and replacing it with the location of the | on the next
> line - that's a much more elegant, and I don't think people use |2 that
> much. We might be able to simplify/get rid of chomping while at it, by
> using "-alone-in-the-next-line for a chomped literal block, so we'll be
> able to get rid of |- as well. That's probably not used much either.
>
> Getting rid of directives also makes sense - basically, keeping the same
> data model but saying "this data is provided externally to the parser, we
> don't mandate how this is done". This would simply the syntax.
>
> Doing some sort of schema language would help - "we don't mandate how the
> data is specified, but a recommended way is to allow loading a schema file
> in this format". Again, this needs more thought.
>
> There are probably other proposals along these lines. We should spend some
> time actively polling people for ideas. "What is your least favorite part
> of YAML, and how would you fix it".
>
> Making it explicit the type repository is 1.1 and not 1.2 and people
> shouldn't use it is also important. It is creating misconceptions (repeated
> in this thread), e.g. about booleans, which are simply not true in 1.2 -
> but implementations get it wrong anyway.
>
> An actually useful ANSI-C reference implementation (some efficient
> low-level tokenizer/streaming parser), usable as a basis for higher level
> libraries, would be great.
>
> For me, that's basically "it".
>
> This means YAML2.0 would "just work out of the box" for "almost all" the
> configuration files out there (and there are a *lot* of these). I think
> that's important. We did something similar when moving from 1.1 to 1.2.
>
> Ingy may have a very different notion for YAML2.0 though - if so, I'd call
> the above YAML1.3. I don't see it as a revolution, I see it as an
> evolution. We should reawaken Clark and see what his take on this is...
>
> Have fun,
>
> Oren Ben-Kiki
>
>
> ------------------------------------------------------------------------------
> 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