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-20 00:16:18
|
/************************************************************************* ** RCS-ID: $Id: yaml.h,v 1.3 2001/05/15 16:03:13 cce Exp $ ** Copyright: (c) 2001 Clark Evans (cc...@cl...) ** License: You may use under the Python, Perl, or LGPL license ** Credits: Brian Ingerson and Oren Ben-Kiki ** Version: This is a prototype API and is not yet ** ready for implementing ************************************************************************/ /************************************************************************* * CONTEXT AND CONSTANTS ************************************************************************/ struct yaml_context; typedef char yaml_char_t; /* typedef for unicode */ typedef size_t yaml_size_t /* buffer size in bytes */ typedef void * yaml_user_t; /* user defined ptr */ typedef const yaml_char_t * yaml_key_t; /* null terminated str */ typedef const yaml_char_t * yaml_name_t; /* null terminated str */ typedef struct yaml_context * yaml_context_t; /* iter/visit context */ typedef void * yaml_reference_t; /* opaque handle */ typedef enum { YAML_ERROR = -1, YAML_SUCCESS = 0, } yaml_result_t; typedef enum { YAML_NODE_SCALAR = 1, YAML_NODE_LIST = 2, YAML_NODE_MAP = 3, YAML_NODE_REF = 4 } yaml_type_t; struct yaml_context /* this structure holds the current iterator or visitor context, which is the path up to the root node. */ { yaml_context_t parent; /* the parent context, maintained for you */ yaml_type_t type; /* the type of node, this is Map, List, */ yaml_key_t key; /* if an entry in a map, this is the key */ yaml_reference_t reference; /* the reference for the value's content */ yaml_name_t name; /* the class name or data type */ yaml_user_t user; /* user defined object for this context */ }; /************************************************************************* * VISITOR INTERFACE ************************************************************************/ struct yaml_visitor; /* the visitor event handler and data pointer */ typedef struct yaml_visitor * yaml_visitor_t; typedef enum { YAML_VISIT_ERROR = YAML_ERROR, YAML_VISIT_CONTINUE = YAML_SUCCESS, /* continue visiting */ YAML_VISIT_STOP, /* stop visiting, free visitor */ YAML_VISIT_SKIP /* skip children */ } yaml_visit_t; typedef /* when entering a node (map, list, or scalar) */ yaml_visit_t (*yaml_visit_enter_t)( yaml_visitor_t visitor, yaml_context_t context); typedef /* when exiting node (map, list, or scalar) */ yaml_visit_t (*yaml_visit_exit_t)( yaml_visitor_t visitor, yaml_context_t context); typedef /* for scalar content, can be called more than once per node */ yaml_visit_t (*yaml_visit_chars_t)( yaml_visitor_t visitor, yaml_context_t context, const yaml_char_t* data, yaml_size_t size ); typedef /* reference is encountered, note this does not dereference */ yaml_visit_t(*yaml_visit_ref_t) (yaml_visitor_t visitor, yaml_context_t context); struct yaml_visitor { yaml_visit_ref_t ref; /* function to handle reference events */ yaml_visit_enter_t enter; /* function to handle begin node event */ yaml_visit_exit_t exit; /* function to handle end node event */ yaml_visit_chars_t chars; /* function to handle scalar content */ yaml_user_t user; /* user data for the consumer */ }; /************************************************************************* * ITERATOR INTERFACE ************************************************************************/ struct yaml_iterator; /* the iterator data producer and user data ptr */ typedef struct yaml_iterator * yaml_iterator_t; typedef enum { YAML_ITER_ERROR = YAML_ERROR, /* bad, some error occurred */ YAML_ITER_NONE = YAML_SUCCESS, /* good, but no node encountered */ YAML_ITER_SCALAR = YAML_TYPE_SCALAR, /* good, scalar node encountered */ YAML_ITER_LIST = YAML_TYPE_LIST, /* good, list node encountered */ YAML_ITER_MAP = YAML_TYPE_MAP, /* good, map encountered */ YAML_ITER_REF = YAML_TYPE_REF /* good, reference encountered */ } yaml_iter_t; typedef /* iterates through list of siblings in a list or map */ yaml_iter_t (*yaml_iter_next_t)( yaml_iterator_t iterator, yaml_context_t *context); typedef /* iterates into the first child of a list or map */ yaml_context_t *context); typedef /* allows the return of scalar data, returns amount read */ yaml_size_t (*yaml_iter_chars_t)( yaml_iterator_t iterator, yaml_char_t* data, yaml_size_t size); typedef /* stops the iteration and cleans up iterator */ yaml_iter_t (*yaml_iter_stop_t)( yaml_iterator_t iterator); struct yaml_iterator { yaml_iter_next_t next; /* function to return next yaml node */ yaml_iter_first_t first; /* function to return first yaml node */ yaml_iter_chars_t chars; /* function to return scalar content */ yaml_iter_stop_t stop; /* function to stop the iteration */ yaml_user_t user; /* user data for the producer */ }; /************************************************************************* * PARSER/EMITTER API ************************************************************************/ yaml_iterator_t yaml_parse( FILE * ); yaml_visitor_t yaml_emit( FILE * ); yaml_result_t yaml_exec(yaml_iterator_t,yaml_visitor_t); /* To stream a document though the system: * * yaml_exec( yaml_parse(fopen("file.in","r")), * yaml_emit(fopen("file.out","w"))); */ /************************************************************************* * PARSER/EMITTER API ************************************************************************/ typedef struct { yaml_iterator_t iterator, yaml_visitor_t visitor } * yaml_convert_t; yaml_convert_t yaml_convert(void); |
From: Clark C . E. <cc...@cl...> - 2001-05-19 21:29:28
|
I started to write the spec using a format similar to the W3C's XML specification. Ugly unless you have an HTML editor. Anyway, I think I'm going continue using YAML syntax... Clark |
From: Neil W. <neilw@ActiveState.com> - 2001-05-19 20:58:10
|
In Perl: ----8<---- if ($a > 5 and $b < 10) { print "YAPL!\n"; } else { print "DAPL!\n"; } ---->8---- In YAMPL(?): ----8<---- if : @ @ @ and @ > a 5 @ < b 10 @ print "YAPL!\n" @ 1 @ print "DAPL!\n" ---->8---- Here's what the parsed YAML would look like in Perl: (trimmed for brevity) ----8<---- $VAR1 = { if => [ [ [ 'and ', [ '>', 'a', '5' ], [ '<', 'b', '10' ] ], [ 'print', 'YAPL!\\n' ], [ '1' ], [ 'print', 'DAPL!\\n' ] ] ] }; ---->8---- Neil |
From: Clark C . E. <cc...@cl...> - 2001-05-19 20:49:40
|
On Sat, May 19, 2001 at 01:37:31PM -0700, Neil Watkiss wrote: | How about a yak and a camel mixed together? What would | that look like anyways? *falls down laughing* ;) Clark P.S. I'm at irc.debian.org #yaml if anyone would like to join. |
From: Brian I. <briani@ActiveState.com> - 2001-05-19 20:37:46
|
"Clark C . Evans" wrote: > > I was wondering... has anyone thought of what > a YAML might look like? I'll put my logo designer on it. Really. Brian -- perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf ("Just Another %s Hacker",x);}};print JAxH+Perl' |
From: Neil W. <neilw@ActiveState.com> - 2001-05-19 20:37:38
|
How about a yak and a camel mixed together? What would that look like anyways? Neil On Sat, 19 May 2001, Clark C . Evans wrote: > I was wondering... has anyone thought of what > a YAML might look like? > > Clark > > _______________________________________________ > Yaml-core mailing list > Yam...@li... > http://lists.sourceforge.net/lists/listinfo/yaml-core > |
From: Neil W. <neilw@ActiveState.com> - 2001-05-19 20:36:36
|
A dodo. Neil On Sat, 19 May 2001, Clark C . Evans wrote: > I was wondering... has anyone thought of what > a YAML might look like? > > Clark > > _______________________________________________ > Yaml-core mailing list > Yam...@li... > http://lists.sourceforge.net/lists/listinfo/yaml-core > |
From: Clark C . E. <cc...@cl...> - 2001-05-19 20:26:51
|
I was wondering... has anyone thought of what a YAML might look like? Clark |
From: Clark C . E. <cc...@cl...> - 2001-05-19 20:08:01
|
I. Introduction 1. Goals a. Very readable by humans b. Optimized for interpreted languages c. Uses the language's native data structures d. Allows binary and large formatted text nodes e. Works well with internet mail architecture f. Includes a stream based interface g. Consistent information model 2. Target Domains a. Program configuration files b. Log file formats c. Textual RPC via SMTP d. Structured business documents 3. Related Technologies a. Python b. Perl c. XML and SOAP d. RFC 822, Internet Mail e. RFC 2045/6, MIME 4. Summary II. Specification 1. Information Model a. Nodes b. Indicators 2. Scalar a. Folded b. Quoted c. Block 3. Lists 4. Maps 5. References 6. Classes 7. Document 8. RFC 882 Headers 9. RFC 2045/6 MIME a. References b. Transfer Encoding III. Programming 1. Native Interface a. Python b. Perl c. Java d. Javascript c. C++ 2. Sequential Interface in C a. Iterator b. Visitor 3. Components in C a. Parser b. Emitter c. Converter d. Filters 4. Applications a. Configuration File b. Log file c. Sendmail target d. Filter Application |
From: Brian I. <briani@ActiveState.com> - 2001-05-19 19:59:35
|
"Clark C . Evans" wrote: > Yep. The syntax has very much taken shape unless > someone finds a monkey-wrench. I'm starting to > work on the specification -- and I will first post > an outline and then I'll start heading for the > first draft in the next 4 hours (at 8 I have > mandatory, externally imposed social time... > as if this isn't social... *grin*) Have fun! BTW, Post what you have each hour or so if it's no trouble. I'd like to follow along. |
From: Brian I. <briani@ActiveState.com> - 2001-05-19 19:56:51
|
"Clark C . Evans" wrote: > | > We don't need a subset. When the RFC822 headers are > | > given, the YAML content is the *body* which is not > | > parsed by other RFC822 tools. > | > | OK. So, that means the next time we propose an option for the YAML body > | that doesn't resemble 822, I don't want to hear opposing arguments based > | on 822. Fair? > > Almost fair. RFC822 "consistency" should be considered, > but certainly is not a key factor. For example, given > that python uses : to indicate identing and that RFC 822 > uses : for key/value seperator, this gives us extra points > if we are somewhat consistent with both... Yup. That makes sense. I was just weary of getting shutdown for seemingly nonsensical 822 reasons. Consistency is good, but not to a fault. ,Brian -- perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf ("Just Another %s Hacker",x);}};print JAxH+Perl' |
From: Brian I. <briani@ActiveState.com> - 2001-05-19 19:49:08
|
Oren Ben-Kiki wrote: > > "There's always one more"... > > I got a way around the need to "further indent" the second line in a list > block value, given Clark's new white space handling rules (which I like): > > list @ > value1 > value2 > |block > |value3 > \ > |value4 - block with an empty > | > \line followed by a longer on > |e which was broken > \ > |value5 - verbatim single line > value6 > > That is, in a list, a block ends by an empty \ line, at least if followed by > another block. It may be simpler/more readable to require "a block ends with > an empty \" everywhere in lists: > > |verbatim single line value5 > \ > value6 > > What do you think? OK. I get it now. All three of us had a different spin on what '\' means. I like everything above except where '\text' means a line continuation. I like Clark's (mis)interpretation that it means there is no trailing newline on that line (which can *only* happen on the last line). We'll ignore *my* complicated interpretation. This means that: 1) A '|' means implicit newline. 2) A '\' means no implicit newline. 3) Every block ends with a '\' line. It's that simple! I can completely buy into this. (I just wish I had thought of it ;) BTW, There is no mechanism for continuation. (The block is truly verbatim.) Here's my example revisited: list : @ "a stream value" another stream value "yet another stream value" \ single line block sans T-NL | single line block *with* T-NL \ | multi | line block \ with no T-NL | another | multi-line | *with* no T-NL \ \\ single block with leading backslash "\\ single stream with leading backslash" "\\" \\ The last two represent a single backslash in stream and block respectively. (The block may have trailing whitespace, but no trailing newline) > At any rate, no scalar marker required, ever. How about it, Brian? Can we > agree on the 'minimal' option, based on this? As ammended? With great pleasure :) , Brian |
From: Clark C . E. <cc...@cl...> - 2001-05-19 19:39:28
|
On Sat, May 19, 2001 at 12:25:18PM -0700, Brian Ingerson wrote: | As a note of interest, Jeff Hobbs asserted that "" was superior to \" | because you could parse forward and backwards the same way. But his | model did not include folded whitespace, \n, etc. I think \" is fine for | our purposes. Yes, that is neat, but we have to worry about \n and its pals. Also, \" is familar to most programmers. | I'm in favor. I didn't really see the purpose of the intermittent | non-folding rule anyways. '\ ' or '\s' is fine for this. good deal. | | BTW, Do we support \x05 style escaping in streams. | I wouldn't mind. Might be useful. Yes, of course! | PS I feel like we are getting somewhere again. Yep. The syntax has very much taken shape unless someone finds a monkey-wrench. I'm starting to work on the specification -- and I will first post an outline and then I'll start heading for the first draft in the next 4 hours (at 8 I have mandatory, externally imposed social time... as if this isn't social... *grin*) ... On a related topic, I'd be interested in what you think about class names? Best, Clark |
From: Brian I. <briani@ActiveState.com> - 2001-05-19 19:28:34
|
"Clark C . Evans" wrote: > > Ok. I just took a walk (to fetch more coffee) and I like > your quoted string proposal Brian. Although I do think > that the " character has to be escaped. I also like your > proposal since it works for key values as well and this > was an open item on my list. OK. Probably a better choice to be more retrictive at this point anyway. As a note of interest, Jeff Hobbs asserted that "" was superior to \" because you could parse forward and backwards the same way. But his model did not include folded whitespace, \n, etc. I think \" is fine for our purposes. > > On the other hand, during the walk, I was thinking > about this pathalogic case: > > key: > this is a double spaced paragraph that cannot be folded > > Interstingly enough, I went through the RFC822 once > more (the next day) and the behavior of this > pathalogic case in an "unstructured field" is ambiguous... > on one hand folding is allowed where ever there is > whitespace and on the other, trailing whitespace > is snipped. > > So, unless I have further objection, I'm going > to move back to the "simpler" version of whitespace > folding found in HTML and the structured fields of > RFC 822. Thus, any sequence of one or more whitespace > characters is folded by the parser into a single space, > forcing \n, \t and \ escaping for explicit whitespace. > This rule holds for "quoted strings" => "quoted strings" > as well as unquoted strings. This rule is suspended > for block scalars. I'm in favor. I didn't really see the purpose of the intermittent non-folding rule anyways. '\ ' or '\s' is fine for this. BTW, Do we support \x05 style escaping in streams. I wouldn't mind. Might be useful. I definitely want "no escaping" for blocks. , Brian PS I feel like we're getting somewhere again. -- perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf ("Just Another %s Hacker",x);}};print JAxH+Perl' |
From: Brian I. <briani@ActiveState.com> - 2001-05-19 19:16:39
|
"Clark C . Evans" wrote: > > On Sat, May 19, 2001 at 10:24:56AM -0700, Brian Ingerson wrote: > | Soooo. Here's my latest based on everthing to date, including my last > | double quoted streams idea. > | > | list : @ > | "a stream value" > | another stream value > | "yet > | another > | stream > | value" > | \ single line block w/ trailing newline > | \ single line block; no T-NL \ > | | multi > | | line block > | \ with no T-NL > | | another > | | multi-line > | \ with no T-NL\ > | \\ single block with leading backslash > | "\\ single stream with leading backslash" > | "\\" > > Hmm. I would have read this differently.... please comment... > > list: > \ single line block without a trailing new line > | single line block *with* a trailing new line > \ > \\ single line block with a leading backslash and w/o new line I had changed the semantic of '\' to mean the last line. But now I think I understand Oren's semantic, and it is just as good if not better. I'll review Oren's again and get back to you. > "\\ single quoted block with a leading backslash and w/o new line" Quoted things are not "blocks". They are "streams". That is your terminology. Anyway I agree with all of the above. > > | \\\ > | > | The last two represent a single backslash in stream and block > | respectively. > > I don't like the very last one, I think non-quoted Well, that's because I was using different rules. With your/Oren's rules: "\\" \\ Mean the same thing. And that's good. The first is a stream and the second is a block. (Technically the block could have trailing whitespace. Which is perfectly fine.) > stream blocks should be forbidden to begin with > \ " | % $ or any of our other special characters. Hmm. I agree. Because canonically, streams are always double quoted. BTW, Please don't say "stream block" again. It's an oxymoron in your/our current terminology. > > | I like this scheme because: > | > | A) It doesn't add any new quoting characters. > | B) It's clear and obvious if you understand the 3 characters. > | C) It doesn't add extra lines just for termination. > | D) Doesn't require "bullets" or indenting. > | E) Deterministic in regards to quoting markup characters > | and other edge cases. > | > | I'm not giddy about the "trailing backslash to eliminate a final > | newline", but I don't hate it either. And it's the rarer of > | occurences. I hereby rescind the notion of trailing backspace, and adopt Oren's notion of blocking. I'll double check his post one more time. , Brian |
From: Clark C . E. <cc...@cl...> - 2001-05-19 18:55:31
|
| I like the idea of allowing optional RFC822 headers before a YAML doc. | I don't like the idea of them imposing any further restrictions on YAML. | That's a very slippery slope. Agreed. | > We don't need a subset. When the RFC822 headers are | > given, the YAML content is the *body* which is not | > parsed by other RFC822 tools. | | OK. So, that means the next time we propose an option for the YAML body | that doesn't resemble 822, I don't want to hear opposing arguments based | on 822. Fair? Almost fair. RFC822 "consistency" should be considered, but certainly is not a key factor. For example, given that python uses : to indicate identing and that RFC 822 uses : for key/value seperator, this gives us extra points if we are somewhat consistent with both... Best, Clark |
From: Clark C . E. <cc...@cl...> - 2001-05-19 18:49:38
|
On Sat, May 19, 2001 at 10:24:56AM -0700, Brian Ingerson wrote: | Soooo. Here's my latest based on everthing to date, including my last | double quoted streams idea. | | list : @ | "a stream value" | another stream value | "yet | another | stream | value" | \ single line block w/ trailing newline | \ single line block; no T-NL \ | | multi | | line block | \ with no T-NL | | another | | multi-line | \ with no T-NL\ | \\ single block with leading backslash | "\\ single stream with leading backslash" | "\\" Hmm. I would have read this differently.... please comment... list: \ single line block without a trailing new line | single line block *with* a trailing new line \ \\ single line block with a leading backslash and w/o new line "\\ single quoted block with a leading backslash and w/o new line" | \\\ | | The last two represent a single backslash in stream and block | respectively. I don't like the very last one, I think non-quoted stream blocks should be forbidden to begin with \ " | % $ or any of our other special characters. Hmm. | I like this scheme because: | | A) It doesn't add any new quoting characters. | B) It's clear and obvious if you understand the 3 characters. | C) It doesn't add extra lines just for termination. | D) Doesn't require "bullets" or indenting. | E) Deterministic in regards to quoting markup characters | and other edge cases. | | I'm not giddy about the "trailing backslash to eliminate a final | newline", but I don't hate it either. And it's the rarer of | occurences. | | ,Brian | | -- | perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf | ("Just Another %s Hacker",x);}};print JAxH+Perl' | | _______________________________________________ | Yaml-core mailing list | Yam...@li... | http://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Clark C . E. <cc...@cl...> - 2001-05-19 18:43:02
|
Ok. I just took a walk (to fetch more coffee) and I like your quoted string proposal Brian. Although I do think that the " character has to be escaped. I also like your proposal since it works for key values as well and this was an open item on my list. On the other hand, during the walk, I was thinking about this pathalogic case: key: this is a double spaced paragraph that cannot be folded Interstingly enough, I went through the RFC822 once more (the next day) and the behavior of this pathalogic case in an "unstructured field" is ambiguous... on one hand folding is allowed where ever there is whitespace and on the other, trailing whitespace is snipped. So, unless I have further objection, I'm going to move back to the "simpler" version of whitespace folding found in HTML and the structured fields of RFC 822. Thus, any sequence of one or more whitespace characters is folded by the parser into a single space, forcing \n, \t and \ escaping for explicit whitespace. This rule holds for "quoted strings" => "quoted strings" as well as unquoted strings. This rule is suspended for block scalars. Best, Clark |
From: Brian I. <briani@ActiveState.com> - 2001-05-19 17:47:50
|
Brian Ingerson wrote: > Soooo. Here's my latest based on everthing to date, including my last > double quoted streams idea. > > list : @ > "a stream value" > another stream value > "yet > another > stream > value" > \ single line block w/ trailing newline > \ single line block; no T-NL \ > | multi > | line block > \ with no T-NL ^W This should have read 'with T-NL' Sorry. > | another > | multi-line > \ with no T-NL\ > \\ single block with leading backslash > "\\ single stream with leading backslash" |
From: Brian I. <briani@ActiveState.com> - 2001-05-19 17:44:30
|
"Clark C . Evans" wrote: > > RFC822 solves many different things: > > 1) It gives a place to put document level meta-data > that is not part of the content, such as the YAML-Version > and the character encoding. > > 2) It allows for BLOBs via MIME, and any mail reader > (mutt for instance) can read our format and break > out the various BLOBs, allowing them to be viewed > (and possibly edited) seperately. > > 3) It makes YAML very compatible with most mail > processing systems out-of-the-box. If an RFC822 > header is allowed, point a YAML parser at it > to extract the data. I like the idea of allowing optional RFC822 headers before a YAML doc. I don't like the idea of them imposing any further restrictions on YAML. That's a very slippery slope. > > Also, RFC822 isn't that hard (especially the subset > of treating structured headers as unstructured headers). > > | One benefit is that a YAML parser won't have to implement > | the strange RFC822 text parsing rules, ever. > > Yes, these would be an exception... but given that > we treat all structured fields as unstructured it > really isn't that much code... far less than 50 lines, > MIME excepted (which is probably another 150-200 lines). Agreed. Stop worrying about implementation. That's our *job*. > > | I'm catching Brian's headache when trying to > | figure these out, and I have no confidence at all > | in being able to define a subset which is (1) simple > | and (2) will work on most existing such headers. > | Clark is being optimistic here, I think; definitely > | his current white space rules aren't such a subset. > > We don't need a subset. When the RFC822 headers are > given, the YAML content is the *body* which is not > parsed by other RFC822 tools. OK. So, that means the next time we propose an option for the YAML body that doesn't resemble 822, I don't want to hear opposing arguments based on 822. Fair? Brian -- perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf ("Just Another %s Hacker",x);}};print JAxH+Perl' |
From: Brian I. <briani@ActiveState.com> - 2001-05-19 17:28:14
|
Oren Ben-Kiki wrote: > > "There's always one more"... > > I got a way around the need to "further indent" the second line in a list > block value, given Clark's new white space handling rules (which I like): > > list @ > value1 > value2 > |block > |value3 > \ > |value4 - block with an empty > | > \line followed by a longer on > |e which was broken > \ > |value5 - verbatim single line > value6 I like the no indenting notion. > > That is, in a list, a block ends by an empty \ line, at least if followed by > another block. It may be simpler/more readable to require "a block ends with > an empty \" everywhere in lists: But I want it to be done without the requirement of a extra terminating line. > > |verbatim single line value5 > \ > value6 and you again haven't addressed the "no final newline" caveat. > > What do you think? > > At any rate, no scalar marker required, ever. How about it, Brian? Can we > agree on the 'minimal' option, based on this? We're getting closer Oren. (Probably not. But I'm a die-hard optimist :) Soooo. Here's my latest based on everthing to date, including my last double quoted streams idea. list : @ "a stream value" another stream value "yet another stream value" \ single line block w/ trailing newline \ single line block; no T-NL \ | multi | line block \ with no T-NL | another | multi-line \ with no T-NL\ \\ single block with leading backslash "\\ single stream with leading backslash" "\\" \\\ The last two represent a single backslash in stream and block respectively. I like this scheme because: A) It doesn't add any new quoting characters. B) It's clear and obvious if you understand the 3 characters. C) It doesn't add extra lines just for termination. D) Doesn't require "bullets" or indenting. E) Deterministic in regards to quoting markup characters and other edge cases. I'm not giddy about the "trailing backslash to eliminate a final newline", but I don't hate it either. And it's the rarer of occurences. ,Brian -- perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf ("Just Another %s Hacker",x);}};print JAxH+Perl' |
From: Clark C . E. <cc...@cl...> - 2001-05-19 17:17:37
|
On Sat, May 19, 2001 at 10:19:12AM +0200, Oren Ben-Kiki wrote: | | That is, in a list, a block ends by an empty \ line, at least if followed by | another block. It may be simpler/more readable to require "a block ends with | an empty \" everywhere in lists: | | |verbatim single line value5 | \ | value6 | | What do you think? It does work and it eliminates an exception! I like it when exceptions are removed! | | Also, speaking of Clark's latest E-mails about whitespace handling, | maybe we should re-think the whole RFC822 issue. RFC822 solves many different things: 1) It gives a place to put document level meta-data that is not part of the content, such as the YAML-Version and the character encoding. 2) It allows for BLOBs via MIME, and any mail reader (mutt for instance) can read our format and break out the various BLOBs, allowing them to be viewed (and possibly edited) seperately. 3) It makes YAML very compatible with most mail processing systems out-of-the-box. If an RFC822 header is allowed, point a YAML parser at it to extract the data. Also, RFC822 isn't that hard (especially the subset of treating structured headers as unstructured headers). | One benefit is that a YAML parser won't have to implement | the strange RFC822 text parsing rules, ever. Yes, these would be an exception... but given that we treat all structured fields as unstructured it really isn't that much code... far less than 50 lines, MIME excepted (which is probably another 150-200 lines). | I'm catching Brian's headache when trying to | figure these out, and I have no confidence at all | in being able to define a subset which is (1) simple | and (2) will work on most existing such headers. | Clark is being optimistic here, I think; definitely | his current white space rules aren't such a subset. We don't need a subset. When the RFC822 headers are given, the YAML content is the *body* which is not parsed by other RFC822 tools. | If we give up on it we could also use '=' for separating | keys and values. Python uses ":" | Using Clark's notion that the default key is the empty one: | | point % | x % | = 1.2 | accuracy = 0.1 I do like the idea of an empty key. But the above could just as easily be written using colon! ;) | That's the neatest solution so far, I think... | | I'm signing out for the next day or so - flying away to my XP conference. | I'll try to catch up on my E-mail Sunday evening (my time). Have Fun Oren! ;) Clark |
From: Clark C . E. <cc...@cl...> - 2001-05-19 17:05:34
|
Interesting.... | e: "Last night, I had beers with Jeff Hobbs, a very bright guy from | the Tcl community (oxymoron? ;). We didn't get into *great* detail on | YAML but he had a strong suggestion on string syntax. It involved, | wonder of wonders, the double quote." | | I just cut and pasted the above paragraph into e. It parses fine! Now we | can dump huge pieces of text into YAML and (with a little escaping by | hand) just let the emitter clean things up for us. Hmm. Let me chew on this for a while. You seem to have "cut&paste" as a driving use-case. I do think that a specilized editor may be needed for us to really move forward. I see a few options: (a) We could make a simple "ed" like tool for command line junkies. (b) We could write a syntax module for scintilla, by modifying the python module. (c) We could (anyone?) write an emacs mode for YAML. I'm going to chew on this one... but I'm not sure that this use case is good enough to "break" our nice hierarchy! (which is a tenant of our markup, no?) Best, Clark |
From: Brian I. <briani@ActiveState.com> - 2001-05-19 16:18:47
|
I was going to put this into my reply to Oren's block syntax proposal, but I decided that's another issue altogether. BTW, I'm thinking that one over too. I'll reply later today. --- I want to propose yet another way of doing "streams" as we are now calling them. Last night, I had beers with Jeff Hobbs, a very bright guy from the Tcl community (oxymoron? ;). We didn't get into *great* detail on YAML but he had a strong suggestion on string syntax. It involved, wonder of wonders, the double quote. My proposal is adapted from that discussion. The basic idea is that you start every string with a double quote, and just keep going (regardless of line breaks) until you hit the next (unescaped) double quote. Let's try: a: "value" I know. Bear with me. b: "Another value" c: "Another value" Semantically the same as c. d: "Another value" Boggle? But it works because whitespace is insignificant in streams. So indentation is not enforced at all by the *parser*, only by the *emitter*. And this is huge because: e: "Last night, I had beers with Jeff Hobbs, a very bright guy from the Tcl community (oxymoron? ;). We didn't get into *great* detail on YAML but he had a strong suggestion on string syntax. It involved, wonder of wonders, the double quote." I just cut and pasted the above paragraph into e. It parses fine! Now we can dump huge pieces of text into YAML and (with a little escaping by hand) just let the emitter clean things up for us. f: "Last night, I had beers with Jeff Hobbs, a very bright guy from the Tcl community (oxymoron? ;). We didn't get into *great* detail on YAML but he had a strong suggestion on string syntax. It involved, wonder of wonders, the double quote." This is how the value *might* get emitted. Works fine in lists too (per Oren's new ideas on minimal lists): g: @ "value" "Another value" "Works fine in lists too (per Oren's new ideas on minimal lists):" --- Obviously we can omit the quotes on simple values. I'll let Clark come up with the escaping rules, etc. BTW, I'm not even sure we *have* to escape double quotes, unless they come at the end of a line. Just a thought. Brian -- perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf ("Just Another %s Hacker",x);}};print JAxH+Perl' |
From: Clark C . E. <cc...@cl...> - 2001-05-19 16:13:39
|
On Sat, May 19, 2001 at 12:19:56AM -0700, Brian Ingerson wrote: | I was chatting on IRC to some Perl gurus who suggested that YAML is no | more a Markup Language than MIDI. Or than a kayak is an automobile. (To | quote them) | | Their point is that a Markup Language marks up text documents. XML is a | data language that can reasonably markup text as well. YAML is not. | (This was their assertion.) First, we are advertising ourselves as specilizing in data serilization. Second, *yawn*, they are just plain wrong (this will be in the FAQ I can see) markup n. a. The collection of detailed stylistic instructions written on a manuscript that is to be typeset. b. Computer Science. The collection of tags that describe the specifications of an electronic document, as for formatting. The primary difference between YAML and HTML is that HTML has named lists, where we do not -- thus our conventions may be different and they might not like the conventions; I personally dislike HTML's conventions. In any case, we can certainly use YAML to provide the above services. | For instance, how would YAML markup: | | <QUOTE>I went to <A HREF="http://www.webvan.com">Webvan</A> to | get my groceries</QUOTE> One must start with the text being marked up, in this case... I went to Webvan to get my groceries. And then give you the markup rules: (a) the whole thing is designated as a QUOTE (b) WebVan is a link to http://www.webvan.com So, here is a YAML marked up using HTML like conventions (the .val means "content of" ) QUOTE: I went to A % HREF: http://www.webvan.com .val: Webvan to get my groceries They may argue that the above isn't obvious. It certainly is to me, since it directly mirrors the data structures as laid out in-memory. I'd say that the equivalent HTML isn't obvious. Let us take another example. Markup: In math class today, I learned that 3 < 4 & 5 < 6. I also learned that addition is difficult. The markup rule, is that the above need to be described as a paragraph! First the YAML. P: | In math class today, I learned that | 3 < 4 & 5 < 6. I also learned that \ addition is difficult. The HTML... <P>In math class today, I learned that<BR> 3 < 4 & 5 < 6. I also learned that<BR> addition is difficult.</P> For this example, I think HTML is the looser. This game is all a matter of taste. Our tastes are different. To Mrs. Helen Antwerp, a retired news paper editor, who edited articles from World War II (1938) up to very recently (1983) and is now in her 80's, neither the above YAML, nor the HTML is _real_ markup. Everyone knows that real markup is something you do to a printed page with a pen for heaven sakes! Kind Regards, Clark P.S. If you want to talk about "obviousness" we can discuss the XML/HTML processing model and the DOM. This is definatley *not* obvious. For example, if you have adjacent text nodes in your DOM, save your DOM as XML, and then re-load your DOM, all of your indexes will be off since the adjacent text nodes will be merged. This ain't obvious. |