Clark C . Evans [mailto:cce@...] wrote:
> 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?
Yes, sorry. Like I said I need to do a good pass on all the examples.
> A more general observation: you changed from
> mapping to keyed, and sequence to series
> to avoid name conflict with the transfer
Correct. Now there is no confusion between the separate models.
> 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)
I'd say that the parser reports the transfer type of each node and I expect
that there would be an API to add private regexps (there *is* wording in the
spec allowing for it, as long as all the patterns start with "^`").
> 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.
Triplet: (transfer method, anchor, string buffer). The parser doesn't handle
anchors/aliases, it just reports them.
> 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).
The *output* of the loader, in C/C++, is an instance of a YamlNode, which
has a native type designator and a value. There's no trace of the original
anchor, transfer method, or string (in case of a non-text value).
> 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
> transfer method.
The spec suggests this object to be a map with certain keys. Doing that
provides a standard way for applications to deal with such objects.
> 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.
Right. I expect a well-behaved loader to have flags saying whether it should
also choke on unknown transfer methods and untransformable values.
> 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.
The way I see it the whole issue has much less relevance in Perl... For
example, the native data structures are given by the language, so one
doesn't have to invent YamlNode. This means you simply don't have the option
of carrying "forbidden" data with the final native objects. Also,
implementing a proper streaming API in Perl would be interesting, but it
isn't clear it would require a transfer representation. It may be possible
to provide it by incremetally filling the normal native data structures
(using a "sliding window" approach).
> Note that six and seven create a bit of
> indeterminism when the particilar implict
> type is not known but the data is invalid.
Right. Also with key equality etc.