What: YAML Phone Conference
When: 2002-06-14 12:00:00 EST
Present: [Oren, Brian, Clark, Steve, Ryan]
Steve raised issue that the current specification
does not allow for escape folded (a feature in the
Oren noted that with the new changes, we do have
a multi-line quoted form which could work as it is
close to folded. Thus, we have two scalar styles
that do escaping.
There are two use cases for escaping. The first is
that we need someway to represent 7-bit non-printable
ASCII characters, 0x00-0x1F as well as the same range
with the 8th bit high (plus DEL), 0x7F-0xA0. The
second is a way to express unicode sequences using
an ASCII only editor.
There are many unicode aware editors now, and even
upcoming unicode aware xterm programs. Even Notepad
on Windows is unicode aware. Therefore, the second
use case above shouldn't be a driving factor...
Steve noted that block and folded are othogonal to
escaping. This is a clean observation.
Since double quoted strings can now span multiple
lines, the escaped form is redundant. We've decided
to just drop the escaped form.
At a later time we can always add escaping back
as a modifier to block or folded scalar styles.
Often times it is helpful to add extra new lines at the
end of a scalar to enhance readability. There are three
cases relevant to this request:
1. You don't want any trailing new lines in the
content, but you do want them in your YAML file.
Thus, new lines trailing in YAML can be tossed
2. You only want one trailing new line in the content
regardless of how many trailing new lines are
in the YAML file. This is the behavior described
in the current specification.
3. You want all of the trailing new lines in the
YAML serialization to show up as content.
We decided to put "chomp" back into the specification
via the (-) character to support the first requirement. To meet
the third character we will introduce a "keep" modifier (+)
to handle the case where all trailing new lines are signficant.
Suppose you have a block that ends with two new lines that
are different, say one is CR and the other is CRLF. Which
one gets reported? This is an arbitrary choice, and I suggest
that the very first one should be kept.
Brian discussed the question as to the meaining of the
information model diagram having NATIVE -> viewer -> GENERIC.
This seemed confusing as the dumper could work on either the
native or generic model depending on the implementation.
This is a tough one to explain, let alone to get concensus on.
Oren agreed to block NATIVE/GENERIC in a single block to make
the situation a bit more ambiguous since it could be either way.
(Wait till you see the next pass before questions emerge)
We had a problem of confusoin between the usage of the word-char
production and the implicit text type. It made Clark make a few
suggestions (posted on the list).
Clark withdrew the suggestions, Oren agreed to clarify.
In an older version of the spec (one day earilier, for those who
want to read it) there was a mmodel of YAML in YAML used for
explanation. Clark belived that it wassn't helping, so it got
removed. What should we do with it?
We've agreed to write it up as a paper and see how useful
it is by gettting comments from the penut gallery. If it is
really helping, then we'll add it to the spec (as an appendix)
Otherwise we will keep it in the documentation of our website.
How do we manage all of these versoins with slightly
different interpretations of the spec.
We build from Brian's ysh regression and put this up on the
Wiki, modifying as we find other use cases/examples.
It was raised that "in-line" (got a better word, anyone?) forms
get a bit problematic with comments. The possibility of
comments makes it impossible to strip begin and end and treat
the chunk as a single-line form (unless you strip the comments
We think that this does complicate things, but it is useful
so it is just a complexity that parsers will have to cope with.