A few more nit-picks:
A. The first example by throw away comments is a
multi-line scalar... which are now forbidden.
B. In the 4.5.2 example, !keyed is used as
a transfer method. Should be !map, no?
A more general observation: you changed from
mapping to keyed, and sequence to series
to avoid name conflict with the transfer
Also, Brian and I got to talking about how a libyaml
interface would communicate leaf values. We had a
bit of disagreement with regard to the implicit type
mechanism, so I wanted to put this forth.
First, there is a question if implicit types are
the domain of the parser. Since the only implicit
types are the ones specified by the spec and since
this is not extendable by users; I think the answer
here should be yes. That is, implicit typing is
done by the parser (via regex matching)
Second, the question of what is passed on from
the parser to the loader for each scalar. I was
thinking this should logically be a pair
(transfer method, string buffer) and that the
loader should process this appropriately.
Third, what need not be passed on to the
What need not be passed on by the loader
includes (a) if the node was explicitly
or implicitly typed, and (c) the original
string (before style cooking such as
escaping or folding).
Fourth, the parser may also pass along
the scalar style, but this should only
be used for editors, and similar tools.
Fifth, what happens when the loader doesn't
know about the transfer method; in this
case a language specific object wraps the
Sixth, what happens when the data found
in the scalar does not have an appropriate
native representation; such as a
org.yaml.int transfer method with a string
value of 99999999999999999999999999999999.
In this case, it should be wrapped via a
language specific object (as above)
Seventh, what happens when the string
representation is in error... let's
say an integer transfer method with
a string value of "eleventeen". This
should be an error and not wrapped.
Eight, should !int be cooked into
'org.yaml.int' by the parser. I think
yes, as it is just a syntax short-hand.
Likewise, !.int should also be expanded
by the parser.
So. I'm not sure where brian stands
on each of these, but I thought we'd
put this one out.
Note that six and seven create a bit of
indeterminism when the particilar implict
type is not known but the data is invalid.