RE: [Yaml-core] Multiple Thoughts

[Oren Ben-K. <or...@ri...>]

Brian Ingerson [mailto:in...@tt...] wrote:
> > > I would like to propose we use 
> > > a more relaxed form. It boils down to this: ...
> > 
> > My problem with this is that it closes the growth path to 
> > MIME. Using my
> > proposal above, we could always adopt MIME features when/if 
> > we want them.
> > More importantly, in my proposal one can always append the 
> > YAML document to
> > an appropriate header which would turn the YAML document 
> > into a valid MIME
> > one.
> 
> I really don't want to support a growth path to *anything*. 
> If someone can
> easily make YAML look like MIME (or anything else for that matter),
> without it being a requirement, I'm all for it.

There's always some price to be paid for such compatibilities...
> But I think 
> the full MIME
> rules you've suggested are to ugly and restrictive to be 
> mandatory in YAML.

Ugly?

---

log: file
entry: here
---

another: entry
follows: here

Restrictive?

--my-separator

---: Hey, this works now!
--my-separator

...

> I'd be just as happy to scrap the MIME idea as a whole and 
> just go back to:
> 
>     '---' eol

OK, let's see the issues:

1. using only "---" as a separator (as opposed to "--<anything>"). I've no
problem with restricting the separator to '---', though I don't see much
point in it.

2. Making the first separator in a stream optional. I'm uneasy about this,
but I can't quite put my finger on an example showing why it is a problem.

If I understand correctly, 1+2 is what you want. Right?

3. Requiring an empty line after the separator, before the YAML document
itself.

This is the minimum we need for some sort of MIME compatibility. It allows
me to feed a YAML document as-is into any MIME system. So, at a pinch, I'd
go with 1+2+3. I think (hope) that's something you could live with.

4. Allowing certain fixed MIME headers between the separator and the empty
line.

This allows us a natural place to add meta-data about the YAML document,
such as version etc. For maximal MIME compatibility there would be a list of
acceptable headers (YAML version, Content Type, etc.) with fixed valid
values.

This is required for the other type of compatibility with MIME - it allows
me to cut certain MIME messages and feed the data directly into any YAML
system. However, this is less useful then the other direction: MIME systems
are going to filter their data anyway, they might as well strip the headers
off before passing it to the YAML system. In fact, that's their default
behavior anyway.

So, I consider 4 to be a "nice to have" at this stage, rather than vital.

Giving up 4, how about we agree on using the least restrictive form of each
of the options? 1: use '--<anything>', (2) - make the separator optional,
(3) - require the empty line after the separator. Can we agree on that?

Clark tried to formulate this in a form of BNF productions. The above makes
it simpler:

	document ::= bom? separator? top_level (separator top_level)*
	separator ::= '--' pchr+ eol eol

Pretty simple. OK?

Have fun,

	Oren Ben-Kiki