Re: [Yaml-core] Re: New Spec Version

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

On 28/01/02 16:52 -0000, Oren Ben-Kiki wrote:
> Brian Ingerson [mailto:in...@tt...] wrote:
> > I understand D and think it is a reasonable alternative even though it
> > is more restrictive than what we have today. But before I 
> > agree with it,
> > I would like to attempt to argue that it isn't really necessary.
> 
> Up to a point...
> 
> > Consider this: In a pull-based parser interface, it will be 
> > necessary to
> > have an interface which returns a "partial leaf"...
> > ... The
> > next call might then return a comment. And the following call 
> > return the rest
> > of the leaf. 
> 
> Sure, no problem about that, but consider that in this case,
> if (D) is not accepted, the parser may return a comment chunk
> and only then a chunk of the leaf value *which started before
> the comment chunk* it previously reported. In fact, the parser
> may report any number of comment chunks and then a leaf value
> which started before all of them.

No. I don't see it that way. The parser just returns the next chunk, whether
it be a comment or a part of the leaf. Everything is still in order. The
application just needs to expect either.

> It is perfectly reasonable for a parser only interested in
> the graph or tree model. But writing an editor which has to
> work at the syntax model would be a PITA, I think... Think
> syntax coloring, collapsing of chunks, etc. - all these
> would have to deal with what amounts to an interleaving
> of two separate "streams" in a line level (value and
> comments).

No problem, as described above.

> What (D) does is allow for editors etc. handle a YAML stream
> as a sequence of chunks, each with a well-defined syntactical
> meaning (either a comment or "one node"). This would be much
> simpler to handle in such tools, I think.
> 
> > I'm also still in favor of chomping all trailing NL characters. This
> > implementation issue is easily solved by a counter as Clark 
> > pointed out.
> 
> Sure, that's option (C), and it is perfectly reasonable, as
> you point out, as long as the hardship for editors etc. is
> deemed acceptable.
> 
> > So perhaps no changes are needed :)
> 
> Hmmm. The current spec does limit folding to NL characters
> (preserving LS and PS), but chomping is not defined in these
> terms - it says *all* line breaks are chomped, not just NL.
> So even (C) is a change... The question is, do we change
> the spec to option (C) or to option (D)?
> 
> I'm still leaning a bit towards (D) due to its simplicity
> for syntax-level tools (and, I think, simplicity for human
> readers as well).

I fail to see the relationship between C and D. Aren't they separate issues?

I thought:

C) How trailing newlines are handled in chomp mode.

D) Whether comments can occur in a leaf.

Obviously we're not in sync here. Please restate the issues for me.

Cheers, Brian