You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(101) |
Jun
(157) |
Jul
(89) |
Aug
(135) |
Sep
(17) |
Oct
(86) |
Nov
(410) |
Dec
(311) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(76) |
Feb
(100) |
Mar
(139) |
Apr
(138) |
May
(234) |
Jun
(178) |
Jul
(271) |
Aug
(286) |
Sep
(816) |
Oct
(50) |
Nov
(28) |
Dec
(137) |
2003 |
Jan
(62) |
Feb
(25) |
Mar
(97) |
Apr
(34) |
May
(35) |
Jun
(32) |
Jul
(32) |
Aug
(57) |
Sep
(67) |
Oct
(176) |
Nov
(36) |
Dec
(37) |
2004 |
Jan
(20) |
Feb
(93) |
Mar
(16) |
Apr
(36) |
May
(59) |
Jun
(48) |
Jul
(20) |
Aug
(154) |
Sep
(868) |
Oct
(41) |
Nov
(63) |
Dec
(60) |
2005 |
Jan
(59) |
Feb
(15) |
Mar
(16) |
Apr
(14) |
May
(19) |
Jun
(16) |
Jul
(25) |
Aug
(19) |
Sep
(7) |
Oct
(12) |
Nov
(18) |
Dec
(41) |
2006 |
Jan
(16) |
Feb
(65) |
Mar
(51) |
Apr
(75) |
May
(38) |
Jun
(25) |
Jul
(23) |
Aug
(16) |
Sep
(24) |
Oct
(3) |
Nov
(1) |
Dec
(10) |
2007 |
Jan
(4) |
Feb
(5) |
Mar
(7) |
Apr
(29) |
May
(38) |
Jun
(3) |
Jul
(1) |
Aug
(17) |
Sep
(1) |
Oct
|
Nov
(11) |
Dec
(16) |
2008 |
Jan
(11) |
Feb
(4) |
Mar
(7) |
Apr
(48) |
May
(17) |
Jun
(9) |
Jul
(6) |
Aug
(12) |
Sep
(5) |
Oct
(7) |
Nov
(4) |
Dec
(11) |
2009 |
Jan
(15) |
Feb
(28) |
Mar
(12) |
Apr
(44) |
May
(6) |
Jun
(16) |
Jul
(6) |
Aug
(37) |
Sep
(107) |
Oct
(24) |
Nov
(30) |
Dec
(22) |
2010 |
Jan
(8) |
Feb
(16) |
Mar
(11) |
Apr
(28) |
May
(9) |
Jun
(26) |
Jul
(7) |
Aug
(25) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
(5) |
Feb
(6) |
Mar
(3) |
Apr
(2) |
May
(10) |
Jun
(44) |
Jul
(11) |
Aug
(8) |
Sep
(6) |
Oct
(42) |
Nov
(19) |
Dec
(5) |
2012 |
Jan
(23) |
Feb
(8) |
Mar
(9) |
Apr
(11) |
May
(2) |
Jun
(11) |
Jul
|
Aug
(18) |
Sep
(1) |
Oct
(15) |
Nov
(14) |
Dec
(8) |
2013 |
Jan
(5) |
Feb
(13) |
Mar
(2) |
Apr
(10) |
May
|
Jun
(6) |
Jul
(17) |
Aug
(2) |
Sep
(3) |
Oct
|
Nov
(11) |
Dec
|
2014 |
Jan
|
Feb
(1) |
Mar
(10) |
Apr
(12) |
May
(1) |
Jun
(9) |
Jul
(27) |
Aug
(5) |
Sep
(13) |
Oct
(9) |
Nov
(9) |
Dec
|
2015 |
Jan
(8) |
Feb
(5) |
Mar
(1) |
Apr
(10) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(14) |
Nov
(1) |
Dec
(6) |
2016 |
Jan
(12) |
Feb
(12) |
Mar
(133) |
Apr
(7) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(3) |
Nov
(5) |
Dec
|
2017 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
(1) |
Jun
(8) |
Jul
(2) |
Aug
(2) |
Sep
(8) |
Oct
(2) |
Nov
(8) |
Dec
(1) |
2018 |
Jan
(1) |
Feb
(2) |
Mar
(6) |
Apr
|
May
(1) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
(2) |
Feb
(2) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
(1) |
Dec
(2) |
2020 |
Jan
(5) |
Feb
|
Mar
(2) |
Apr
(6) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
(5) |
Feb
(2) |
Mar
(6) |
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
|
Aug
(5) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
(4) |
2022 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(1) |
Dec
(1) |
2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(2) |
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Clark C . E. <cc...@cl...> - 2001-05-18 16:00:46
|
----- Forwarded message from "Clark C . Evans" <cc...@cl...> ----- Date: Fri, 18 May 2001 09:48:50 -0500 From: "Clark C . Evans" <cc...@cl...> Subject: Re: Meeting Minutes On Fri, May 18, 2001 at 12:41:20AM -0700, Brian Ingerson wrote: | I don't think it's that important to investigate. It will probably | always be a moot point. I will let Data::Denter use it's current scheme | to deterministically round-trip all Perl data structures. YAML.pm | probably will have no need for this. It's all acadenic and I have no | spare time for academics for three more months. (My guess is, yes it | could be made to work, but would be suboptimal for Perl people) Let's | leave it at that for now. Ok. I'm curious about what syntax you will deploy. | On 4 & 5. I don't really like the blank line at the beginning thing | because people will mess it up or not understand it. And we have many | heuristic options. | | A) Parse lookahead for X-YAML-Version | B) Option-A rarely needed because as soon as we see a key that is *not* | RFC822 compliant, we assume YAML. 99% of the time this is the first | line! | C) If there is no whitespace allowed before the colon in RFC822, we | simply make it a requirement in YAML. Or does this break your RFC | compatability rules? A&B are good. I don't really care about C, perhaps in the interest of consistency with both RFC822, but also Python code, we may not want to require the space before the colon. | Just for my own edification, would you please explain the rationale | behind making YAML RFC822 compliant. And do so with one of more specific | examples. Thanks :) I'm not all that concerned about RFC822 compliance. I'm more concerned about consistency since we are going to allow RFC822 headers. In particular, if someone sees a few RFC822 lines above and the YAML lines below the seperating blank line, they will most likely assume that YAML has the same (or very similar rules). Thus, those items _common_ in RFC822 should be allowed in YAML. There will be a laundry list of RFC822 constructs that when moved into the YAML section will be illegal. | Neil and I agree that the normal transport mechanism between Perl and | Python serializer/parsers would definitely *not* be a mailer. And if a | mailer was used, most people wouldn't give a darn about the trailing | whitespace. And if they really did, we could just encode the whole | document anyway. So I now definitely think the best-fit answer is: | | " this is the hash\n key for this example :-) " : #class : | |# My Perl Subroutine | | | | sub version { | | if ($_[0] =~ /\n/) { | | return \ "\to sender"; | | } | | } Nice. Is this fairly "optimal" for your purposes? | Sorry for overloading this example with so many weird things. Not at all. This is good. | I'll just comment on the multiline semantics: | | A) Trailing whitespace is preserved if the transporter preserves it. | B) The content can always be encoded before transport anyway. | C) Nothing is escaped. The content is truly verbatim. A '\' is a '\'. | D) An implicit newline is assumed to be at the end of every line. | E) Note that the '|' is one column back from the actual indentation | level. This is intententional. And it will work even if the indent width | is set to one character wide. (not mandatory, but I like it.) | F) I'd like to push for this always starting on the next line if it is a | map value. It has no relation to RFC822. | | This will work the way I intended it 98% of the time. One question. How are trailing new lines handled? You may want to modify "D" so that there is a new line on every | line, except the last one. Thus to get a trailing new-line, you'd have to do: after : | this has a | trailing new line | before : | | This has a leading new | line, but not a trailing | new line. both: | | This has both a leading | and a trailing new line | another : | this does not have | a trailing new line, | nor a leading new line. Clear? I think it beats :- as far as readability. | > 9. Clark agreed to make a "boostrap" C program | > and upload to source forge. Brian and Neil | > agreed to download and hack at will. | | As I walked to the train station with Neil, he figured out the C | implementation in his head and said he would try to get it done | before bed. Great. I'll focus on the specification today then rather than laying-in-code. | > 16. We made little progress on the scalar indicator | > for lists, to colon or not to colon. It wasn't | > agreed, but Clark thinks this is someone else's | > monkey. If Oren and Brian can't agree within | > 7 days, Clark will put on the dictator cap. | | We traded in the '$' for the ':'. '$' as the last character in a line | meant a multiline scalar was to follow. Converting this semantic to the | ':' leaves us with these represntations: | | key1 : @ | single line | : | classless folded | multi line | another single line | and another | #class &0001 : | classed multi | line | #class &0002 classed single line | % | key : value | @ | ~ | #classy % | key : value | : even this multi line on the same line | as a colon thingy works because there | a little bit of indentation imposed by | colon. (Although I don't love it) | : "Another thingy like above that meets" | "RFC822 wackiness" | : | | 1 | | 1 1 | | 1 1 1 | |Just for completeness :-) Good deal. Your example above, you have two colons: " this is the hash\n key for this example :-) " : #class : Is the second colon a typo, or is it required per this proposal? Best, Clark ----- End forwarded message ----- |
From: Clark C . E. <cc...@cl...> - 2001-05-18 16:00:00
|
----- Forwarded message from Brian Ingerson <briani@ActiveState.com> ----- Date: Fri, 18 May 2001 00:41:20 -0700 From: Brian Ingerson <briani@ActiveState.com> Subject: Re: Meeting Minutes "Clark C . Evans" wrote: > > Thank you all for our meeting. Please > correct any of the items here if you find > them to have error. > > Present: Brian Ingerson, > Clark Evans, > Neil Watkiss, > Oren Ben-Kiki > > 1. Brian stated that he would invstigate Oren's Syntax > and get back with us if it meets Perl's serilization > requirements for hard references. If not, specify > what alternatives we can use. I don't think it's that important to investigate. It will probably always be a moot point. I will let Data::Denter use it's current scheme to deterministically round-trip all Perl data structures. YAML.pm probably will have no need for this. It's all acadenic and I have no spare time for academics for three more months. (My guess is, yes it could be made to work, but would be suboptimal for Perl people) Let's leave it at that for now. > > 2. We agreed on Oren's reference (&*) syntax. > > 3. We agreed on having an optiona RFC 822 Header, > this requires that a YAML text without this > header must begin on line #2. Furthermore, > if an RFC 822 Header is present, then it must > include "X-YAML-Version: 1.0" > > 4. Brian said that he'd investiage the RFC a bit > more specifically relating to the productions. > (I'm not sure if this is necessary... ) On 4 & 5. I don't really like the blank line at the beginning thing because people will mess it up or not understand it. And we have many heuristic options. A) Parse lookahead for X-YAML-Version B) Option-A rarely needed because as soon as we see a key that is *not* RFC822 compliant, we assume YAML. 99% of the time this is the first line! C) If there is no whitespace allowed before the colon in RFC822, we simply make it a requirement in YAML. Or does this break your RFC compatability rules? Just for my own edification, would you please explain the rationale behind making YAML RFC822 compliant. And do so with one of more specific examples. Thanks :) > > 5. We talked at length about multi-line scalar text > nodes. Thus far, we agreed on option D, due to > assumed compatibility with RFC 822. Clark agreed > to verify this compatibility. > > 6. Brian stated that the quoting mechanism was not > good enough for source code or ASCII art, and > backed option F. However, option F does not > explicitly preserve trailing whitespace on a > given line. So Brian suggested using > < > pairs. Oren suggested using single quotes. > Clark asked Brian to come up with something > he likes and propose it. > Neil and I agree that the normal transport mechanism between Perl and Python serializer/parsers would definitely *not* be a mailer. And if a mailer was used, most people wouldn't give a darn about the trailing whitespace. And if they really did, we could just encode the whole document anyway. So I now definitely think the best-fit answer is: " this is the hash\n key for this example :-) " : #class : |# My Perl Subroutine | | sub version { | if ($_[0] =~ /\n/) { | return \ "\to sender"; | } | } Sorry for overloading this example with so many weird things. I'll just comment on the multiline semantics: A) Trailing whitespace is preserved if the transporter preserves it. B) The content can always be encoded before transport anyway. C) Nothing is escaped. The content is truly verbatim. A '\' is a '\'. D) An implicit newline is assumed to be at the end of every line. E) Note that the '|' is one column back from the actual indentation level. This is intententional. And it will work even if the indent width is set to one character wide. (not mandatory, but I like it.) F) I'd like to push for this always starting on the next line if it is a map value. It has no relation to RFC822. This will work the way I intended it 98% of the time. > 7. We agreed, after some discussion, that a YAML > parser must support MIME. We agreed implicity > that it must support base64 encoding. > > 8. We didn't discuss this... but it should be > mentioned that to (a) support unicode and > (b) support RFC 822, our texts must be UTF-8. > Thus a YAML parser/writer will default to > UTF-8, although other encoding support is > optional. > > 9. Clark agreed to make a "boostrap" C program > and upload to source forge. Brian and Neil > agreed to download and hack at will. As I walked to the train station with Neil, he figured out the C implementation in his head and said he would try to get it done before bed. > > 10. Oren mentioned that he was thinking of doing > a Java or Javascript implementation. > > 11. Clark agreed to update the spec with the > current agreements. Send me a note when it's changed. I'll review for you. > > 12. Brian mentioned that he'd show YAML to one of > his Perl friends. (sorry I didn't catch his name) Damian Conway http://www.csse.monash.edu.au/~damian/ > > 13. Clark and Brian discussed the MIME usage. > > 14. Clark introduced a very short discussion on > the need for a global mechanism to uniquely > identify names in a non-language specific > manner. > > 15. Clark agreed to write up the "single vs multi" > line controversy and post to the list so that > it is clearly understood. > > 16. We made little progress on the scalar indicator > for lists, to colon or not to colon. It wasn't > agreed, but Clark thinks this is someone else's > monkey. If Oren and Brian can't agree within > 7 days, Clark will put on the dictator cap. We traded in the '$' for the ':'. '$' as the last character in a line meant a multiline scalar was to follow. Converting this semantic to the ':' leaves us with these represntations: key1 : @ single line : classless folded multi line another single line and another #class &0001 : classed multi line #class &0002 classed single line % key : value @ ~ #classy % key : value : even this multi line on the same line as a colon thingy works because there a little bit of indentation imposed by colon. (Although I don't love it) : "Another thingy like above that meets" "RFC822 wackiness" : | 1 | 1 1 | 1 1 1 |Just for completeness :-) > > 17. It is nice to have Neil in on the talk! > > Ok. Thank you all for attending > > Kind Regards, > > Clark > -- perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf ("Just Another %s Hacker",x);}};print JAxH+Perl' ----- End forwarded message ----- |
From: Clark C . E. <cc...@cl...> - 2001-05-18 15:58:43
|
----- Forwarded message from "Clark C . Evans" <cc...@cl...> ----- Date: Fri, 18 May 2001 02:00:39 -0500 From: "Clark C . Evans" <cc...@cl...> Subject: Meeting Minutes Thank you all for our meeting. Please correct any of the items here if you find them to have error. Present: Brian Ingerson, Clark Evans, Neil Watkiss, Oren Ben-Kiki 1. Brian stated that he would invstigate Oren's Syntax and get back with us if it meets Perl's serilization requirements for hard references. If not, specify what alternatives we can use. 2. We agreed on Oren's reference (&*) syntax. 3. We agreed on having an optiona RFC 822 Header, this requires that a YAML text without this header must begin on line #2. Furthermore, if an RFC 822 Header is present, then it must include "X-YAML-Version: 1.0" 4. Brian said that he'd investiage the RFC a bit more specifically relating to the productions. (I'm not sure if this is necessary... ) 5. We talked at length about multi-line scalar text nodes. Thus far, we agreed on option D, due to assumed compatibility with RFC 822. Clark agreed to verify this compatibility. 6. Brian stated that the quoting mechanism was not good enough for source code or ASCII art, and backed option F. However, option F does not explicitly preserve trailing whitespace on a given line. So Brian suggested using > < pairs. Oren suggested using single quotes. Clark asked Brian to come up with something he likes and propose it. 7. We agreed, after some discussion, that a YAML parser must support MIME. We agreed implicity that it must support base64 encoding. 8. We didn't discuss this... but it should be mentioned that to (a) support unicode and (b) support RFC 822, our texts must be UTF-8. Thus a YAML parser/writer will default to UTF-8, although other encoding support is optional. 9. Clark agreed to make a "boostrap" C program and upload to source forge. Brian and Neil agreed to download and hack at will. 10. Oren mentioned that he was thinking of doing a Java or Javascript implementation. 11. Clark agreed to update the spec with the current agreements. 12. Brian mentioned that he'd show YAML to one of his Perl friends. (sorry I didn't catch his name) 13. Clark and Brian discussed the MIME usage. 14. Clark introduced a very short discussion on the need for a global mechanism to uniquely identify names in a non-language specific manner. 15. Clark agreed to write up the "single vs multi" line controversy and post to the list so that it is clearly understood. 16. We made little progress on the scalar indicator for lists, to colon or not to colon. It wasn't agreed, but Clark thinks this is someone else's monkey. If Oren and Brian can't agree within 7 days, Clark will put on the dictator cap. 17. It is nice to have Neil in on the talk! Ok. Thank you all for attending Kind Regards, Clark ----- End forwarded message ----- |
From: Clark C . E. <cc...@cl...> - 2001-05-18 15:56:35
|
----- Forwarded message from "Clark C . Evans" <cc...@cl...> ----- Date: Thu, 17 May 2001 14:20:50 -0500 From: "Clark C . Evans" <cc...@cl...> To: Oren Ben-Kiki <or...@ri...>, Brian Ingerson <briani@ActiveState.com> Subject: YAML: Scalar Syntax Quoting / Folding Ok. Here is a summary of the concensus thus far: 1. It is agreed that whitespace folding with C style escaping for whitespace \n and \t is very useful, especially in the context of indented hierarchy. 2. It is agreed that some sort of MIME mechanism will be included so that images and large formattetd text can be specified as a scalar value without disrupting the tree 3. It is agreed that for ASCII art, where spacing is important, that the whitespace folding technique is very ugly and that we should find an additional method beyond the attachment and escaping mechanism is needed. 4. Due to rfc822 compatibility, we must allow a scalar to start right after the colon and continue on subsequent lines, thus blurring the difference between "single" and "multi-line" scalar values. 5. We would like class names, reference identifiers, and other meta data to occur on a single line along with the scalar value. Given this concensus we have the following options: A. Only have whitespace folding and attachments, only allow single line scalars without meta-data. Problem: Does not solve #3 and #5 B. Distinguish between single and multiple line values. Only allow single line scalars without meta-data. Perserve spacing for single-line scalars. Problem: Prevents #4, #5 and is a weak solution to #3 due to single line. ... Notes: There are variants on A and B where we allow scalar and meta data on the same line, but this does not help #3. C. Distinguish between single and multiple line values, allowing single line scalars with meta data, or one line preserved space scalars using quotes. Problem: Still bad for #4 due to the distinction. And also limits #3 to a single line of content. one : $(0003) "quotes required" two : "space is preserved" three : This is folded and can be on multiple lines. D. Allow for multi-line quoted values, where each line has a begin and end quote. Require quotes when the value contains one of the special characters. This is all or nothing, if one line is quoted, all must be quoted. All other whitespace (tabs and new lines) must be escaped. Problems: This makes #3 (art) easier. And doesn't really impact much else, although it adds another special character which folded content cannot begin with. one : $(0003) "quotes required" two : "space is preserved" three : This is folded and can be on multiple lines. four : "This is a quoted single, mixed, or multi " "line value. Spaces are preserved " "just like C strings. Also like C strings, " "\n and \t escapes are necessary for carrriage " "returns." E. Similar to D, but allow quotes to be mixed with folded text. In this case, the \ escape for a space isn't required, but \" must be quoted. Much more flexiblity. Problems: This may be incompatible with rfc822 (in fact, I think it is). Futher, it is a bit harder for a human/parser to grok. one : $(0003) "quotes required" two : "space is preserved" three : This has "is mixed" spacing that can continue on multiple lines. A \n is still needed for new lines. F. Allow for multi-line whitespace significant lines to begin with a | symbol. Much like D, only that | instead of " and a terminating character is not needed. However, this does not look palatable unless used in single xor multi line version, without amitting a mixed line version. Further, with this mechanism, we can suspend slash escaping? Problems: Most programmers will be familar with quoting and not with | blocks. This adds a special character, |, which folded strings cannot include. one : $(0003) quotes not required two : |space is preserved example f: $(0002) |With the pipe on the begin marker, extra |spaces and carriage returns are significant. | Perhaps \ need not be escaped? |This one ends with an extra new line. | Ok. Have I missed anything? I think I prefer choice "D". Best, Clark ----- End forwarded message ----- |
From: Clark C . E. <cc...@cl...> - 2001-05-18 15:54:58
|
----- Forwarded message from "Clark C . Evans" <cc...@cl...> ----- Date: Thu, 17 May 2001 22:22:29 -0500 From: "Clark C . Evans" <cc...@cl...> To: Brian Ingerson <briani@ActiveState.com> Cc: Oren Ben-Kiki <or...@ri...> Subject: Re: YAML & Pointers/References Notes Regarding RFC 2045/6 (MIME). A few things to note: - Provides a way to break E-Mail into several attachments using a divider - Is implemented through a set of RFC822 header lines - Each attachment can be specified with a transfer encoding to keep the mail message below 76 columns. The two most common are base64 which can be used for binary sections, and quoted-printable, which basically truncates each line at 76 columns using an escape mechanism based on the equal sign. - Each section can have it's own character encoding. - Each section can have it's own set of headers, specifically there is an "id" attribute which is of interest. - Just about any mail reader knows how to handle MIME. Impacts: - We need to have leaves that are binary, or formatted raw text. MIME does this nicely. - Instead of concatinating files directly, we may want to just have one added as an attachment. This is interesting way to "aggregate" content. - (Forgotton RFC822 impact) the header must be ASCII, thus UTF16 is not a possibility. Therefore, we should probably support UTF8. MIME is well known, simple, and very workable. Notes: - I have about three implementations that I've found source code for. Most are distributed with a BSD like license, thus we can probably pick the best parts from each implementation - For a native Python/Perl implementation, one could easily use an rfc822/mime compliant package rather than rolling our own... but I think I'll just copy and customize for our purposes (there is a lot of verification stuff for From/To formatting we just don't need). ----- End forwarded message ----- |
From: Clark C . E. <cc...@cl...> - 2001-05-18 15:53:37
|
----- Forwarded message from "Clark C . Evans" <cc...@cl...> ----- Date: Thu, 17 May 2001 22:11:06 -0500 From: "Clark C . Evans" <cc...@cl...> To: Brian Ingerson <briani@ActiveState.com> Cc: Oren Ben-Kiki <or...@ri...> Subject: Re: YAML & Pointers/References (please correct if there are any mis-conceptions) A few summary points about RFC822: - Every internet mail sent relies upon it. ;) - It is just a bunch of headers followed by a single blank line. After the blank line the "message" is user defined. - In the headers, they use "folding" technique. - They also allow for "quoting" within the header. Thus: Header: "Clark" and Header: Clark are identical. The "" are used when spaces are significant and special characters are needed. - The headers are a mapping - The headers are _not_ recursive - The header content can extend on as many lines as one desires, as long as it has a space character in column 1. - Headers beginning with an X- are open to use without an RFC. - For compliance, one must have three headers, "Date", "From", and "To" - There is a nasty comment mechanism using parenthesis which not many people use - Most of the headers are free form, (especially the ones beginning with X-) - A few of the headers have very strict productions, including, as you can imagine Date. - The output of sendmail or any mail transfer agent is an RFC822 document. - RFC882 is the basis for MIME!!! Our impacts: - It looks alot like what we have except we are hierarchical, and we don't have as many nasty exceptions. - I think we will have an optional RFC822 envelope (headers) seperated by a space from the "real" data. This allows us to put in meta-data about our document, including encoding information and processing instructions that arn't part of the data. - This will give us direct ability to have perl/python as the recipient of a mail processing output (using |/my/program in /etc/aliases) and have the YAML library the *only* thing you need to process the mail. - We may want to have our syntax moderately similar so as to be an "extension of RFC822". This helps us with the super nerds since we arn't inventing our own thing, especially from the perspective of the XMLers. - I don't think we need to parse all of the productions, but we should be able to minimally extract the content. - We can use MIME for "attachments" I think we will have a simple rule. If the first set of "maps" contains "X-YAML-Version" then we will assume it is an RFC 822 envelope and treat it appropriately. Thus, we don't have to cater to it too much, but we should be as close as possible without compromising our integrety. Best, Clark ----- End forwarded message ----- |
From: Clark C . E. <cc...@cl...> - 2001-05-18 15:50:29
|
----- Forwarded message from "Clark C . Evans" <cc...@cl...> ----- Date: Thu, 17 May 2001 12:06:34 -0500 From: "Clark C . Evans" <cc...@cl...> To: Brian Ingerson <briani@ActiveState.com>, Oren Ben-Kiki <or...@ri...> Subject: YAML Meeting Agenda for 17-MAY-2001, 10:30 EDT, 7:30 PDT. Subject : Discuss YAML Syntax and Project Plan Date : 17-MAY-2001 Time : 10:30 EDT, 7:30 PST Where : Phone Conference Call Attendee: @ % Name: Brian Ingerson Tele: 604.484.6450 % Name: Clark Evans Tele: 202.544.7775 % Name: Oren Ben-Kiki Tele: ? Comm: Oren, do you want to be conferenced in? It'd be very early your time, but I'll gladly call you (Brian is calling me and I have two way calling). Brian is there a way to record the meeting? I don't have a method. Tasks: @ % Who : All What: Read all e-mail postings by all three parties that is sent by 4:00 EDT. % Who : Clark What: Compile list of alternative syntaxes. % Who : Clark What: Update the web site with current status Topics: @ % What: Review tasks, alternative syntaxes, and introductions Lead: Clark Time: 10 min % What: Discuss pointer/reference item and hopefully reach concensus. Lead: Brian Time: 10 min % What: Discuss scalar type options and hopefully reach concensus. Lead: Clark Time: 10 min % What: Introduce discussion on classes and namespaces. Lead: Clark Time: 5 min % What: Discuss syntax options and hopefully reach concensus. Lead: Brian Time: 10-20 min % What: Discuss web site and project, next steps Lead: Clark Time: 10 min. % What: Discuss implementation plans, for C, Python, and Perl. Lead: Brian Time: 10 min % What: Conclusion and Next Steps Lead: Clark Time: 5 min Total Time: 60-90 min ----- End forwarded message ----- |
From: Clark C . E. <cc...@cl...> - 2001-05-17 16:46:58
|
This is the YAML Core Developer's List. See http:://yaml.org for details. Clark |