Re: Types, byte codes etc.

On 5/10/07, Oren Ben-Kiki <[email protected]> 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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Yaml-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/yaml-core