From: Oren Ben-K. <or...@ri...> - 2001-10-26 14:30:03
|
Clark wrote: > | X. Wrapping YAML > > Interesting. But I don't see other applications "wrapping" > YAML that much. Throw-away comments seem the only example > (right now). And I'd like 2 more examples before we > generalize. Well, we have comments and document stream, that's two :-) > | X.1 Throwaway comments > > Let's try to think hard so that column 0 comments > starting with a # are consistent with the rest > of the model. I don't see how this could work with any sane information model: block: | int main() { # This code sample is so overused! print "Hello, world!\n"; return 0; } I mean, what *can* you do with such a monstrosity? And it is *very* useful, so you can't just ignore it. > If this fails, then we can come back to the notion > of "throw-away" comments. I'd rather have comment > stripping be an application level operation. That's what I was trying to define in "wrapping" - an application level operation. Perhaps a rephrase is in order... > | X.2 Multiple YAML documents in a single stream > > Interesting. From what I remember, MIME has the > following pattern... > > Header: Value > Separate: MIME-SEP > Item: eof eof starts content That's "eol eol"... > > This is content Actually, it isn't. Anything before the first seperator is (should be) ignored, it isn't part of the payload. Good for us, because that makes requiring the first seperator consistent with MIME. > --MIME-SEP > More: Headers > > More content > --MIME-SEP > More: Headers > > etc. > EOF Right. > A few things to note: > > a) Each section is a "map" followed by eof > eof followed by content eol eol, but otherwise yes. Now that you mention this, for my "YAML as subset of MIME" to work, we should have an empty line immediatly after the seperator line: seperator_line ::= '--' seperator <eol> <eol> This way the YAML content won't be mistaken for the header. > b) The separator is named in the first header, > and then the same separator is reused. Yes. In my subset, there's no header, if the first line starts with '--' you assume it is a seperator instead. > c) The More: Headers can specify transfer-encodings. Yes, but we don't want to go there. > d) In this way the MIME-SEP can be made unique > within the content to allow for arbitrary content. Which works in my proposal as well - you are free to choose your seperator. > Interesting thoughts. It would be nice if most regular > e-mail messages happened to also be valid YAML. Certainly > our top-level production is where this compatibility > happens or doesn't happen. This won't happen because of the <eol> <eol> convention, and the fact that mail messages can contain anything, including things which look like YAML but aren't. What we can hope for is: - E-mail (MIME) *headers* being valid YAML (they are). - Multi-document YAML streams being (a subset of) MIME multi-part messages (which they are in my proposal). This way you could parse an E-mail header using YAML, or send a multi-document YAML file using MIME (you just need to add a small header before it). I don't think we can get much more without twisting YAML out of shape - we went there once, remember? Brian was right in making this a non issue, I hope he likes this new idea better :-) Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-10-26 16:13:15
|
I'd rather not have throw-away comments, and I'd rather not have a separate "pre-processing" layer. I'd like to find a simple way to add comments without huge changes to our design. On Fri, Oct 26, 2001 at 04:30:55PM +0200, Oren Ben-Kiki wrote: | > | X.1 Throwaway comments | > | > Let's try to think hard so that column 0 comments | > starting with a # are consistent with the rest | > of the model. | | I don't see how this could work with any sane information model: | | block: | | int main() { | # This code sample is so overused! | print "Hello, world!\n"; | return 0; | } Yikes. Could we just limit this mechanism to only allow comments at the *beginning* of a section (top level sequence)? Then use the comment type for nested uses? #!/usr/bin/function # # This is a 'section' level comment that # is attached to the first section. # map: #: # This is a comment attached to the map by a convention. Since order is not preserved, we will sort the comment keys first. key: value list: - # This is also a multi-line comment. - value ---- # # This is another section level comment # - List item - Another list item - Comments are not allowed between list items Thus, the only "magic" we've added is a sequence of line comments attached to each section. That's not so bad. That can be part of the information model, no? Clark |
From: Clark C . E. <cc...@cl...> - 2001-10-26 16:18:57
|
Something like this looks promising; perhaps it should be visited once more. Anyway, I have to duck out till Tuesday or so. Sorry. Clark On Fri, Oct 26, 2001 at 04:30:55PM +0200, Oren Ben-Kiki wrote: | > | X.2 Multiple YAML documents in a single stream | > | > Interesting. From what I remember, MIME has the | > following pattern... | > | > Header: Value | > Separate: MIME-SEP | > Item: eof eof starts content | That's "eol eol"... | > | > This is content | | Actually, it isn't. Anything before the first seperator is (should be) | ignored, it isn't part of the payload. Good for us, because that makes | requiring the first seperator consistent with MIME. | | > --MIME-SEP | > More: Headers | > | > More content | > --MIME-SEP | > More: Headers | > | > etc. | > EOF | | Right. | | > A few things to note: | > | > a) Each section is a "map" followed by eof | > eof followed by content | | eol eol, but otherwise yes. Now that you mention this, for my "YAML as | subset of MIME" to work, we should have an empty line immediatly after the | seperator line: | | seperator_line ::= '--' seperator <eol> <eol> | | This way the YAML content won't be mistaken for the header. | | > b) The separator is named in the first header, | > and then the same separator is reused. | | Yes. In my subset, there's no header, if the first line starts with '--' you | assume it is a seperator instead. | | > c) The More: Headers can specify transfer-encodings. | | Yes, but we don't want to go there. | | > d) In this way the MIME-SEP can be made unique | > within the content to allow for arbitrary content. | | Which works in my proposal as well - you are free to choose your seperator. | | > Interesting thoughts. It would be nice if most regular | > e-mail messages happened to also be valid YAML. Certainly | > our top-level production is where this compatibility | > happens or doesn't happen. | | This won't happen because of the <eol> <eol> convention, and the fact that | mail messages can contain anything, including things which look like YAML | but aren't. What we can hope for is: | | - E-mail (MIME) *headers* being valid YAML (they are). | - Multi-document YAML streams being (a subset of) MIME multi-part messages | (which they are in my proposal). | | This way you could parse an E-mail header using YAML, or send a | multi-document YAML file using MIME (you just need to add a small header | before it). I don't think we can get much more without twisting YAML out of | shape - we went there once, remember? Brian was right in making this a non | issue, I hope he likes this new idea better :-) |
From: Brian I. <in...@tt...> - 2001-10-26 17:41:09
|
On 26/10/01 16:30 +0200, Oren Ben-Kiki wrote: > Clark wrote: > > | X.1 Throwaway comments > > > > Let's try to think hard so that column 0 comments > > starting with a # are consistent with the rest > > of the model. > > I don't see how this could work with any sane information model: > > block: | > int main() { > # This code sample is so overused! > print "Hello, world!\n"; > return 0; > } There is no problem here. The comment would be stripped. It can't be part of the block. It's not indented. BTW, your block indentation is wrong. YAML uses tabs ;) Also, *what* programming language is that supposed to be? Cheers, Brian |