On Fri, Oct 9, 2009 at 7:44 AM, David Golden <xda...@gmail.com> wrote: > 06. Data structures, not YAML > > Proposal: > > The META spec should be defined in terms of (Perl) data structures, and not > in terms of YAML. (Slaven Rezic) > > Comments: > > * This does not mean that I want to replace YAML by a Perl data dump (or > maybe yes, but see below). It is just about the specification document: > it should not talk about "META.yml", but the META spec, and should not > use the YAML data type names (mapping, sequence), but Perl data type > names (hash, array).
Agreed. > * The actual serialization proposals could go into an appendix of the spec, > or even in a new document. So whether it will be JSON, or YAML::Tiny, or > YAML 1.1 could be decided later. I like the idea of different sections for "data", "serialization", and "usage" (the latter being how clients use it.) > * In my opinion I would vote for *two* serialization formats: normal YAML > as it is done currently (or even YAML 1.1), which would be used for > statistical analysis (here we can force people to install the latest and > greatest YAML parser), and a Perl data dump which is used by CPAN.pm etc. > for configure_requires or similar stuff (here the user has probably a > very bare perl installation, the minimum we can expect is the ability to > parse Perl). Something similar is done with distroprefs handling in > CPAN.pm: if .yml is available, fine, otherwise it's possible to fallback > to .dd, a perl data dump file. I don't like having .dd as an option. We want to minimize evaluated code. > * I am still fine that the examples in the spec are still expressed in > YAML, because I think that YAML is a quite nice human-readable format. I'm be in favor of replacing all examples with Perl data structures, since they will map more clearly to how they will be generated and how they will exist after deserializing. We're talking about a spec for Perl programmers, so I think that's probably sufficiently "human-readable". -- David
