From: Brad B. <bm...@ma...> - 2007-05-11 13:54:24
|
On 5/10/07, Oren Ben-Kiki <or...@be...> wrote: > > On Thu, 2007-05-10 at 10:24 -0400, Brad Baxter wrote: > > > So my question/point-of-discussion is: Could the newlines separating > > tokens in the canonical structure be replaced with spaces and still > > allow a YAML parser to correctly parse the structure? > > Almost. > > > Currently, > > the answer is no for at least three reasons: > > > > comments: # comment > > If you are going for a one-liner, you'd probably want to strip away the > comments anyway. Remember they are essentially a form of white space, > just like indentation, which also can't be conveyed in a one-line > format :-) That sounds reasonable--they should be a cinch to strip out. > directives: %YAML 1.2, %TAG !o! tag:ben-kiki.org,2000: > > Stickier problem. Yes, these need to be each on their own line. That > said... on a one-liner, you would probably get rid of them as well, say > by using verbatim tag. Less readable, but you have throw readability out > the door already anyway. BTW, this is what we'll be doing in the > canonical/byte code format. Just to be sure I caught that right, you're saying that the canonical format will replace all symbolic tags with verbatim tags? Will the above directives be absent, then? > end of document markers: ... > > We can write one object per line: > > --- { ... } > --- { ... } > > Multiple objects in the same line is cheating :-) Good point. What was I thinking? :-) > There may be others, but these are the ones I found that seem to > > rely on a newline to end them. > > I don't think there are any others. > > > I don't know about "need", but I for one would not mind being able > > to store serialized objects in a flat file, one object per line. > > You can do that, as shown above. Minus the comments. > > > I guess the bottom line is simply this: Why not allow a YAML > > stream, in its canonical form, to fit on a singe line? > > While this might have been an interesting requirement to pursue a few > years back, at this point it would require making changes to the spec > and barring a compelling use case (like we had for JSON compatibility), > we won't be doing that. I understand, and I appreciate the feedback. It sounds to me like I'll get what I want. I look forward to giving it a try. -- Brad |