Re: [Yaml-core] Proposed Changes to YAML Spec

[Brian I. <in...@tt...>]

On 18/07/01 12:14 +0200, Oren Ben-Kiki wrote:
> Brian Ingerson [mailto:in...@tt...] wrote:
> > 1) No tabs allowed in indenting. It is invalid YAML.
> >
> > 2) All indenting is mandatory 4 spaces.
>
> We can live with that...

Great!

>
> > 3) Blocks are represented like:
> >
> > foo:
> >     line 1
> >       line 2
> >     line 3
> > bar: -
> >     multi-line
> >     with no final new line
>
> Two issues:
>
> 1. It seems we can say there are only two formats,
> "quoted" and "block". The "block" format uses the
> syntax we initially used for "simple scalars",
> including the single-line:
>
>     foo: This is a block value!

Disagree. This is a simple scalar which ignores leading and trailing
whitespace and has no trailing newline.

Same as:

    foo: "This is a block value!"
or
    foo:       This is a block value!
or
    foo:       "This is a block value!"

so this is really a block value:

    foo:
        This is a block value!

>
> Quoted strings have escapes, are folded - in short,
> they are "processed". "block" format is taken "as is",
> without any special interpretation of the characters.
> Very neat.

Yes. Agree.

>
> 2. Using '-' to imply "no trailing newline". I think
> we should use something else, to allow for:
>
>     foo: -12.5

Right. I agree. I really only felt weakly about the '-', but threw it
out there for comments. So thanks for jumping on it :)

>
> 3. Considering both (1) and (2), and assuming some
> character X (say we use '\') is used to denote "no
> trailing newline", then to encode a simple number
> (say), one would have to write:
>
>     foo: \1234
>
> When we much rather be able to write:
>
>     foo: 1234

But this is *not* a block. So there is no trailing newline.

>
> The cleanest syntactical way around this is to have
> the default be "with trailing new line" for a multi-line
> value and "without trailing newline" for a single-line
> value. The indicator character would mean "reverse the
> default":
>
>     foo: without newline
>     bar: \with newline
>     baz:
>         with new line
>     boo: \
>         without newline
>
> Clean, for sure. But also slightly confusing.

Since bar and baz are the same, just eliminate bar. baz is not
confusing.

I am fully in favor of just replacing '-' with '\' from my previous
proposal. Both in map and bulleted list context. Sound OK?

> 4. How about we have an indicator for *having* the
> trailing newline included?
>
>     foo: without newline
>     bar: \with newline
>     baz: \
>         with new line
>     boo:
>         without newline
>
> So most multi-line blocks would require the '\'...
> Is this acceptable?

bar can always be

    bar: "with newline\n"

Switch the meaning for baz and boo. I think having a trailing newline is
much more common.

>
> > baz: @
> >     :
> >         Multi line block.
> >         Note (Oren) that the ':' is a
> >         bullet for blocks in list context.
>
> Joy! :-)

Good.

>
> > 4) Top production is a list of maps, but the list
> >    separator is "---\n" instead of "\n".
>
> That makes it easier to include empty lines in blocks,
> I guess. OK.

Right.

> > 5) Multi-line map keys may only be quoted (and possibly escaped). No
> >    block mode allowed.
>
> Why?
>
>     map: %
>         unquoted key: value
>         "quoted key": value
>         multi
>         line key: value
>
> Where's the harm?

Um. Blocks are verbatim. This is not verbatim. What if there were an
actual ':' in the block? I don't think we need to argue this one. It's a
rare case, and quoted w/ escaping can do everything we need.

>
> > These rules allow a very clean YAML, and make for very deterministic
> > parsing. They eliminate the need for a closing '>>' or even a leading
> > '<<' for blocks. They also simplify the heuristics for emitting.
>
> And give us just two scalar forms instead of three!

Depending on what you call:

   foo:     simple string with non-significant WS

This is just the short form of:

   foo:     "simple string with non-significant WS"

Basically it boils down to: "Blocks always start on the next line".

I think that's completely reasonable and obvious.

> Question: what was the verdict about leading/trailing spaces? I think
> we agreed to eliminate them completely in quoted strings. It seems that
> leading/trailing spaces are also removed in the first line (the key line)
> of a block value as well, because the <CR> in:
>
>     foo:<CR>
>         value
>
> is stripped. So:
>
>     foo:  some value
>
> (note both leading and trailing space) is the same as:
>
>     foo: some value
>
> Makes sense?
>
> > Thoughts?
>
> See the above. We may want to change the name "block" to "plain" (so we'll
> have "quoted" and "plain" text).
>
> > FYI, I'm very comfortable with this syntax and will go ahead
> > and use it for my demoes. Clark is currently in agreement as
> > well.
>
> I really like this direction. Merging the "block" and "simple" text
> formats into a single "plain" text format is neat. Let's just clear
> up the issue of the with/out newlines indicator (definitely not '-')
> and the trailing/leading spaces, and I'll roll out a release candidate
> draft this weekend.

So to recap:

Just change '-' to '\'.

Cheers, Brian