On 3/27/06, Clark C. Evans <cce@clarkevans.com> wrote:

That said, if you have specific, concrete suggestions I'd love to hear
them (and most likely shoot them down, but hey, we can try)!

I don't have a suggestion, just an observation.  As regards
human readability/editability, I find one hurdle to be the
fact that plain scalars have so many exceptions.  Simple
examples, like

color: green
title: Kermit's Night Out
chapter: 1

are clear enough, but more complex ones like

color: #c0c0c0
title: Hanna Reitsch: Hitler's Female Test Pilot
chapter: 1[tab]Aviation

Are not so clear.  According to the specs (1.1),
these are not valid plain scalars, so I'd expect to
get error messages loading them, but YAML.pm
version 0.58 (at least) appears to Load them okay
and Dump them as

chapter: 1      Aviation
color: '#c0c0c0'
title: "Hanna Reitsch: Hitler's Female Test Pilot"

In addition, the docs for YAML-0.58 say,

- 123 this is an error

So I would expect "1      Aviation" to have been
Dumped with quotes around it.

I'm so confused!  :-)

From http://yaml.org/spec/current.html#id2535812: . Plain

The plain style uses no identifying indicators, and is
therefore the most most limited and most context sensitive
scalar style. Plain scalars can never contain any tab
characters. They also must not contain the :  and  #
character sequences as these combinations cause ambiguity
with key: value pairs and comments. Inside flow
collections, plain scalars are further restricted to avoid
containing the [, ], {, } and ,  characters as these would
cause ambiguity with the flow collection structure (hence
the need for the flow-in context and the flow-out


The first plain character is further restricted to avoid
most indicators as these would cause ambiguity with various
YAML structures. However, the first character may be -, ?
or : provided it is followed by a non-space character.


All of the above, and particularly that "most indicators" part
of the last sentence make me believe that the safest way
for a human to edit YAML data is always to use quoted
scalars.  I once believed that Perl code was a good config
syntax, e.g.,

$color = 'green';
$title = "Kermit's Night Out";
$chapter = 1;

But when it got around to explaining to mere users how
to edit that syntax, it became clear quickly that it wouldn't
work well.  So I switched to the typical Ini file syntax

color = green
title = Kermit's Night Out
chapter = 1

and everybody was able to handle it.  Moving from that kind
of simplicity to YAML instead would be okay if not for all of
the plain scalar exceptions.  And saying to a user, "Just use
quoted scalars," would move me in the direction of Perl code
again, and I just don't see it working well either.

Is JSON better for this?  Not really--it simply requires quotes
and commas and brackets, etc. rather than leaving them
optional (with exceptions).

Conclusion: I'm not saying that there is anything wrong with
how plain scalars are defined.  I'm just saying that because
of the complexities, it's hard to communicate which are okay
plain scalars and which are not.