From: Oren Ben-K. <or...@ri...> - 2001-07-18 10:13:04
|
Brian Ingerson [mailto:in...@tt...] wrote: > 1) No tabs allowed in indenting. It is invalid YAML. > > 2) All indenting is mandatory 4 spaces. We can live with that... > 3) Blocks are represented like: > > foo: > line 1 > line 2 > line 3 > bar: - > multi-line > with no final new line Two issues: 1. It seems we can say there are only two formats, "quoted" and "block". The "block" format uses the syntax we initially used for "simple scalars", including the single-line: foo: This is a block value! Quoted strings have escapes, are folded - in short, they are "processed". "block" format is taken "as is", without any special interpretation of the characters. Very neat. 2. Using '-' to imply "no trailing newline". I think we should use something else, to allow for: foo: -12.5 3. Considering both (1) and (2), and assuming some character X (say we use '\') is used to denote "no trailing newline", then to encode a simple number (say), one would have to write: foo: \1234 When we much rather be able to write: foo: 1234 The cleanest syntactical way around this is to have the default be "with trailing new line" for a multi-line value and "without trailing newline" for a single-line value. The indicator character would mean "reverse the default": foo: without newline bar: \with newline baz: with new line boo: \ without newline Clean, for sure. But also slightly confusing. 4. How about we have an indicator for *having* the trailing newline included? foo: without newline bar: \with newline baz: \ with new line boo: without newline So most multi-line blocks would require the '\'... Is this acceptable? > baz: @ > : > Multi line block. > Note (Oren) that the ':' is a > bullet for blocks in list context. Joy! :-) > 4) Top production is a list of maps, but the list > separator is "---\n" instead of "\n". That makes it easier to include empty lines in blocks, I guess. OK. > 5) Multi-line map keys may only be quoted (and possibly escaped). No > block mode allowed. Why? map: % unquoted key: value "quoted key": value multi line key: value Where's the harm? > These rules allow a very clean YAML, and make for very deterministic > parsing. They eliminate the need for a closing '>>' or even a leading > '<<' for blocks. They also simplify the heuristics for emitting. And give us just two scalar forms instead of three! Question: what was the verdict about leading/trailing spaces? I think we agreed to eliminate them completely in quoted strings. It seems that leading/trailing spaces are also removed in the first line (the key line) of a block value as well, because the <CR> in: foo:<CR> value is stripped. So: foo: some value (note both leading and trailing space) is the same as: foo: some value Makes sense? > Thoughts? See the above. We may want to change the name "block" to "plain" (so we'll have "quoted" and "plain" text). > FYI, I'm very comfortable with this syntax and will go ahead > and use it for my demoes. Clark is currently in agreement as > well. I really like this direction. Merging the "block" and "simple" text formats into a single "plain" text format is neat. Let's just clear up the issue of the with/out newlines indicator (definitely not '-') and the trailing/leading spaces, and I'll roll out a release candidate draft this weekend. Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2001-07-18 16:14:33
|
Brian Ingerson [mailto:in...@tt...] wrote: > > foo: This is a block value! > > Disagree. This is a simple scalar which ignores leading and trailing > whitespace and has no trailing newline. So, in your view: Is this a legal YAML scalar? is so, of what type? Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2001-07-18 16:47:48
|
On 18/07/01 18:15 +0200, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] wrote: > > > foo: This is a block value! > > > > Disagree. This is a simple scalar which ignores leading and trailing > > whitespace and has no trailing newline. > > So, in your view: Is this > a legal YAML scalar? > is so, of what type? Absolutely. It is the same as foo: "This is a block value!" which is the same as: foo: "This is a block value!" which is different from: foo: " This is a block value!" --- ('---'. Cute eh? :) The following represents 3 spaces: foo: " " --- This: foo: "a value\n" is the same as: foo: a value --- This is invalid yaml: foo-bar-baz: A value which is not valid YAML But this is valid: foo-bar-baz: "A value\n which *is* valid YAML" and is the same as: foo-bar-baz: \ A value which *is* valid YAML --- Cheers, Brian |
From: Oren Ben-K. <or...@ri...> - 2001-07-18 16:42:54
|
OK, I thought about it a bit and here's what I think would be cleanest. It seems to be consistent with Brian & Clark's proposal - more of an extension (actually, removing restrictions) then a real change. Indentation: - Indentation is strict 4-spaces. - Empty lines are allowed (separation of lists by '---'). Scalar types: - We'll have only two types of scalar formats. Quoted scalars: - Surrounded by ". - Leading/trailing whitespace is removed. - White space is folded unless escaped. - Escape sequences allow for non-printables, etc. In short, the same as today's quoted string. Plain scalars: - Not surrounded by ". - Leading and trailing white space in the first line (the same line as the key) is removed. - White space is not folded. - '\' is used to indicate there isn't any trailing newline in a plain text value. - ':' is used to separate multi-line plain values in a list. This is a unification of the block and simple scalar formats. Keys: - Keys are normal scalar values, can be plain or quoted. - A key containing : (or non-printables) must be quoted. This seems to cover everything... It is simple, consistent (has no special cases) and is very clean and human-readable. Examples: foo: a value, no newline bar: a value, with newline baz: \ a value, no newline --- foo: " a value, \ no newline " bar: "a value, \ with newline\n" baz: "a value, \ no newline" --- foo: plain key bar baz: key is "bar\nbaz\n" \ bar baz: key is "bar\nbaz" Thoughts? Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2001-07-18 17:28:22
|
On 18/07/01 18:43 +0200, Oren Ben-Kiki wrote: > OK, I thought about it a bit and here's what I think would be cleanest. It > seems to be consistent with Brian & Clark's proposal - more of an extension > (actually, removing restrictions) then a real change. First off, this is subtly but definitely different than the intent we've come up with (and implemented). > Indentation: > - Indentation is strict 4-spaces. > - Empty lines are allowed (separation of lists by '---'). Yes. > > Scalar types: > - We'll have only two types of scalar formats. I never proposed this. This is just your spin on it. I actually agree that there are two scalar types, but not what you are suggesting. There is quoted and block. For quoted, the quotes can be ommitted only if the the value is single line and there are no special characters. For block, you always start on the next line. That was Clark's and my intent, and the way Neil understood it. > Quoted scalars: > - Surrounded by ". > - Leading/trailing whitespace is removed. > - White space is folded unless escaped. > - Escape sequences allow for non-printables, etc. > In short, the same as today's quoted string. Leading and trailing whitespace are stripped off each line. But double whitespace is not collapsed. Also white space between a double quote and a character is left intact. This would not collapse at all: foo: " QTY PRICE TOTAL " but is different from: foo: QTY PRICE TOTAL which is the same as: foo: "QTY PRICE TOTAL" These are all "Quoted scalars". Feel free to change the name. I really don't care about that. > > Plain scalars: > - Not surrounded by ". > - Leading and trailing white space in the first line > (the same line as the key) is removed. > - White space is not folded. > - '\' is used to indicate there isn't any trailing newline > in a plain text value. > - ':' is used to separate multi-line plain values in a list. > This is a unification of the block and simple scalar formats. > > Keys: > - Keys are normal scalar values, can be plain or quoted. > - A key containing : (or non-printables) must be quoted. No, please. Why do we *need* block here? > > This seems to cover everything... > It is simple, consistent (has no special cases) > and is very clean and human-readable. > > Examples: > > foo: a value, no newline > > bar: > a value, with newline > > baz: \ > a value, no newline > --- > foo: " > a value, \ no newline > " No need to escape double spaces between caharacters. > > bar: "a value, > \ with newline\n" > > baz: > "a value, > \ no > newline" The double-quotes are part of the data, right? > --- > foo: plain key > > bar > baz: key is "bar\nbaz\n" I do not like this. It is not verbatim. Why not just *say* "bar\nbaz\n": key is "bar\nbaz\n" > > \ > bar > baz: key is "bar\nbaz" > > Thoughts? > > Have fun, > > Oren Ben-Kiki > > _______________________________________________ > Yaml-core mailing list > Yam...@li... > http://lists.sourceforge.net/lists/listinfo/yaml-core |
From: Oren Ben-K. <or...@ri...> - 2001-07-18 17:13:01
|
Brian Ingerson [mailto:in...@tt...] wrote: > > So, in your view: Is this > > a legal YAML scalar? > > is so, of what type? > > Absolutely. Then how come: > This is invalid yaml: > > foo-bar-baz: A value which > is not valid YAML They seem identical to me... And I wouldn't want to disallow it. What do you think of my unified proposal? Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2001-07-18 18:32:04
|
On 18/07/01 19:13 +0200, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] wrote: > > > So, in your view: Is this > > > a legal YAML scalar? > > > is so, of what type? > > > > Absolutely. > > Then how come: > > > This is invalid yaml: > > > > foo-bar-baz: A value which > > is not valid YAML > > They seem identical to me... And I wouldn't want to disallow it. What do you > think of my unified proposal? I definitely want to disallow it. It's important to have invalid cases as well as valid ones. If everything is valid then prople will be making semantic mistakes all over the place. Clark? Cheers, Brian |
From: Oren Ben-K. <or...@ri...> - 2001-07-18 19:01:09
|
Brian Ingerson [mailto:in...@tt...] wrote: > On 18/07/01 18:43 +0200, Oren Ben-Kiki wrote: > > OK, I thought about it a bit and here's what I think would > > be cleanest. It > > seems to be consistent with Brian & Clark's proposal - more > > of an extension > > (actually, removing restrictions) then a real change. > > First off, this is subtly but definitely different than the intent > we've come up with (and implemented). I realize that... It is my proposal to change it slightly to make it more orthogonal. > > Indentation: > > - Indentation is strict 4-spaces. > > - Empty lines are allowed (separation of lists by '---'). > > Yes. > > > > > Scalar types: > > - We'll have only two types of scalar formats. > > I never proposed this. This is just your spin on it. Definitely. > I actually agree that there are two scalar types, but > not what you are suggesting. > > There is quoted and block. > > For quoted, the quotes can be ommitted only if the the value > is single line and there are no special characters. Ah, you consider the single line is a special case of quoted, not block... I see. Sort of "unquoted quoted" format :-) So, foo: a backslash \ Is now illegal? Must I write it as: foo: "a backslash\\" Or as: foo: \ a backslash \ I don't like it. I think that unquoted text should behave more like a block - what you see is what you get, and as little restrictions as possible. > That was Clark's and my intent, and the way Neil understood it. If it implies I can't write: regexp: s/\r\n/\n/g Then I don't like it. Neither: quoted: "s/\\r\\n/\\n/g" block: \ s/\r\n/\n/g Are as elegant. I think my way would result in cleaner YAML files... > > Quoted scalars: > > - Surrounded by ". > > - Leading/trailing whitespace is removed. > > - White space is folded unless escaped. > > - Escape sequences allow for non-printables, etc. > > In short, the same as today's quoted string. > > Leading and trailing whitespace are stripped off each line. But > double whitespace is not collapsed. Also white space between a double > quote and a character is left intact. Sorry, I forgot we changed the rules about folding. So there's no more "\ ", right? More changes to the next draft... > > baz: > > "a value, > > \ no > > newline" > > The double-quotes are part of the data, right? My mistake. Quoted scalars must start on the same line as the key. You are right, the above would put the '"' in the value. This is misleading... I guess there's no way around it. > > Keys: > > - Keys are normal scalar values, can be plain or quoted. > > - A key containing : (or non-printables) must be quoted. > > No, please. Why do we *need* block here? Well, if you take my view that: foo: bar Is a degenerate block instead of a degenerate quoted string, then you have to allow (degenerate) blocks for keys... and there's no reason not to allow for the full ones (there's no ambiguity and it is easy to parse). What is the problem with supporting them? > > --- > > foo: plain key > > > > bar > > baz: key is "bar\nbaz\n" > > I do not like this. It is not verbatim. Why not just *say* > > "bar\nbaz\n": key is "bar\nbaz\n" Why not say: code: "main() {\n printf("Hello world\\n");\n}\n" (Besides it being ugly :-). I think: bar baz: foo Is definitely more readable - and even "verbatim" - then using quotes and escapes. BTW, the limitation that some keys can't contain ':' appears in your way as well. For you it is the "unquoted quoted" keys; for me it is any block keys. So, to summarize, I think my rather subtle changes would result in cleaner YAML files, and they are as easy to generate/parse... Clark? Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2001-07-19 00:27:59
|
On 18/07/01 21:02 +0200, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] wrote: > > If it implies I can't write: > > regexp: s/\r\n/\n/g > > Then I don't like it. Neither: Oren, as a compromise, there's no reason why an a single line value with no quotes could be verbatim (unescaped). Then regexp: s/\r\n/\n/g would work as expected. But this is not a block. It is just the behaviour of an unquoted single line value. It has no newline on the end. Leading and trailing whitespace are not significant. Blocks always start on the next line. etc It seems you are bent on reducing this to two scalar rules. Why not just allow three. (It's a luckier number :) 1) Single Value - Always on same line as key - Not escaped (verbatim) - Can't be used for special values like ' ', '%', '@', etc. - No trailing newline - Leading/Trailing whitespace not significant 2) Quoted - Supports single and multi-line values - Same rules as always 3) Block - Always start on next line - Indenting required - Bulleted in lists - Not used for map keys --- I'll tell you what. If you support me on the above, then I will support "full bulleting" for lists: a bulleted list: @ : simple value like s/\r\n/\n/g :) : "Quoted value" : "Another quoted value with multiple lines" : A block value with significant whitespace embedded blank lines and a trailing newline I am going to go ahead and implement a subset of this for my demoes. YAML is actually a miniscule part of what I am doing at the conference. I've already dedicated too much time to this. Cheers, Brian |
From: Brian I. <in...@tt...> - 2001-07-19 00:30:04
|
oops, I meant: > Oren, as a compromise, there's no reason why an a single line value with no > quotes could be verbatim (unescaped). ^^^^^^^^^^^^^^n't |
From: Brian I. <in...@tt...> - 2001-07-18 20:02:48
|
> > I actually agree that there are two scalar types, but > > not what you are suggesting. > > > > There is quoted and block. > > > > For quoted, the quotes can be ommitted only if the the value > > is single line and there are no special characters. > > Ah, you consider the single line is a special case of quoted, not block... I > see. Sort of "unquoted quoted" format :-) So, Yes. I have always thought this from day one. > > foo: a backslash \ > > Is now illegal? Must I write it as: > > foo: "a backslash\\" Yes. > > Or as: > > foo: \ > a backslash \ Yes. > > I don't like it. I think that unquoted text should behave more like a block > - what you see is what you get, and as little restrictions as possible. Well, block lines always have a newline (unless '\' is in effect). So your single line case breaks that rule. > > > That was Clark's and my intent, and the way Neil understood it. > > If it implies I can't write: > > regexp: s/\r\n/\n/g > > Then I don't like it. Neither: A bit bit on the pathological side. > > quoted: "s/\\r\\n/\\n/g" > block: \ > s/\r\n/\n/g This is very reasonable for things like that. > > Are as elegant. I think my way would result in cleaner YAML files... > > > > Keys: > > > - Keys are normal scalar values, can be plain or quoted. > > > - A key containing : (or non-printables) must be quoted. > > > > No, please. Why do we *need* block here? > > Well, if you take my view that: > > foo: bar > > Is a degenerate block instead of a degenerate quoted string, then you have > to allow (degenerate) blocks for keys... and there's no reason not to allow > for the full ones (there's no ambiguity and it is easy to parse). How do you know whether foo has a trailing newline? Multi-line keys are just *not* common at all. Double quotes *can* handle all the cases. > So, to summarize, I think my rather subtle changes would result in cleaner > YAML files, and they are as easy to generate/parse... I would rather have all "Quoted Scalars" require the quotes, than have a simple value be thought of as a block. Clark? Cheers, Brian |
From: Oren Ben-K. <or...@ri...> - 2001-07-19 07:49:42
|
Brian Ingerson [mailto:in...@tt...] wrote: > It seems you are bent on reducing this to two scalar rules. > Why not just allow three. (It's a luckier number :) I also came to this conclusion. Two just isn't enough. We need three because there are three common cases: - Verbatim ("block"). Rarely used, but then it is a must-have (e.g. large amounts of code). - "Everything possible" ("quoted"). More common, but more verbose, is vital for non-printables, indicators, etc. - Plain text ("simple": unquoted, line-wrapped, no escapes). To me this is the most useful type of all. It is the most commonly used format, it is the least verbose, and is what we tend to write in all our examples. We have a difference of opinion on how important "simple" text is. You want to restrict it to one-liners for some reason. I'm not clear on why. I have two problems with this restriction: - You can no longer generate RFC822 headers using a YAML emitter. - You can no longer cut&paste text from, say, an E-mail message, or from a notepad file, or whatever, into a YAML document without worrying about escaping. Example: invoice: % description: The ACME 2001 Widget is a unique product which will replace all the tools in your house! Chosen as "best product of the year" by the Loony Toons Review (TM) and personally recommended by Wile E. Coyote, Genius! Now, according to your proposal, I'd have to quote this text, escape the ", etc. Ugh. So, how about the following compromise. We keep 3 types of text. Quoted: as today. Block: as you proposed, with the slight modification it always has an indicator character: \ if there is no trailing newline (like today) and | if it does have a trailing newline. Simple text: like quoted text except that no escaping is done. As for keys. There's no theoretical reason not to allow all three types for keys (that is, there's no ambiguity in the syntax and parsing is not a problem). That said, I agree to restricting keys to either quoted text or "single-line simple text without :". The need for more complex keys is rare. Samples: block: | with trailing newline. another: \ without trailing newline. "foo\nbar\n" : "quoted text" foo bar: simple text may be multi-line simple: may start on next line quoted: "may do either as well". Compared to your proposal: > 1) Single Value > - Always on same line as key No; and may be multi-line (important!) > - Not escaped (verbatim) Yes > - Can't be used for special values like ' ', '%', '@', etc. No (can be used as long as they aren't the first character) > - No trailing newline Yes (but see below) > - Leading/Trailing whitespace not significant Yes > 2) Quoted > - Supports single and multi-line values yes > - Same rules as always Yes (but see below) > 3) Block > - Always start on next line Yes, but indicator required (| or \) > - Indenting required Yes > - Bulleted in lists Yes > - Not used for map keys Yes Pretty close agreement... As for the "see below"s: I had an unrelated idea about empty lines (now that we allow them). How about the semantics of an empty line in a quoted/simple text would be the same as "\n" (a "hard" newline)? That would allow: text: Text for first paragraph. Text for second paragraph. Neat, right? readability rules! > I'll tell you what. If you support me on the above, then I > will support "full bulleting" for lists: Does the above count as good enough an agreement? :-) Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2001-07-19 13:33:41
|
On 19/07/01 09:50 +0200, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] wrote: > > It seems you are bent on reducing this to two scalar rules. > > Why not just allow three. (It's a luckier number :) > > I also came to this conclusion. Two just isn't enough. We need three because > there are three common cases: > > - Verbatim ("block"). Rarely used, but then it is a must-have (e.g. large > amounts of code). More common than you might think. There are lots of times when you want to preserve whitespace besides code (which seems only to be important to me :). For example: 1) Embedding another YAML doc as a string! 2) Human formatted HTML 3) A columnar ascii table like an invoice. 4) An email like this one 5) Ascii Art See what I mean? > > - "Everything possible" ("quoted"). More common, but more verbose, is vital > for non-printables, indicators, etc. > > - Plain text ("simple": unquoted, line-wrapped, no escapes). To me this is > the most useful type of all. It is the most commonly used format, it is the > least verbose, and is what we tend to write in all our examples. > > We have a difference of opinion on how important "simple" text is. You want > to restrict it to one-liners for some reason. I'm not clear on why. I have > two problems with this restriction: > > - You can no longer generate RFC822 headers using a YAML emitter. > > - You can no longer cut&paste text from, say, an E-mail message, or from a > notepad file, or whatever, into a YAML document without worrying about > escaping. > > Example: > > invoice: % > description: > The ACME 2001 Widget is a unique product which > will replace all the tools in your house! Chosen > as "best product of the year" by the Loony Toons > Review (TM) and personally recommended by Wile E. > Coyote, Genius! > > Now, according to your proposal, I'd have to quote this text, > escape the ", etc. Ugh. > > So, how about the following compromise. We keep 3 types of text. > > Quoted: as today. > > Block: as you proposed, with the slight modification it always has an > indicator character: \ if there is no trailing newline (like today) and | if > it does have a trailing newline. I like this. > > Simple text: like quoted text except that no escaping is done. > > As for keys. There's no theoretical reason not to allow all three types for > keys (that is, there's no ambiguity in the syntax and parsing is not a > problem). That said, I agree to restricting keys to either quoted text or > "single-line simple text without :". The need for more complex keys is rare. I have some "theories", but I won't expound. Let's keep keys simple (and quoted) for now. We can always change later if there is a need. > > Samples: > > block: | > with trailing newline. > another: \ > without trailing newline. > "foo\nbar\n" : "quoted text" > foo bar: simple text > may be multi-line > simple: > may start on next line > quoted: > "may do either as well". > > Compared to your proposal: > > > 1) Single Value > > - Always on same line as key > No; and may be multi-line (important!) OK > > - Not escaped (verbatim) > Yes > > - Can't be used for special values like ' ', '%', '@', etc. > No (can be used as long as they aren't the first character) That's what I meant. > > - No trailing newline > Yes (but see below) > > - Leading/Trailing whitespace not significant > Yes > > > 2) Quoted > > - Supports single and multi-line values > yes > > - Same rules as always > Yes (but see below) > > > 3) Block > > - Always start on next line > Yes, but indicator required (| or \) OK > > - Indenting required > Yes > > - Bulleted in lists > Yes > > - Not used for map keys > Yes > > Pretty close agreement... > > As for the "see below"s: I had an unrelated idea about empty lines (now that > we allow them). How about the semantics of an empty line in a quoted/simple > text would be the same as "\n" (a "hard" newline)? That would allow: > > text: > Text for first > paragraph. > > Text for second > paragraph. > > Neat, right? readability rules! Very cool. > > > I'll tell you what. If you support me on the above, then I > > will support "full bulleting" for lists: > > Does the above count as good enough an agreement? :-) I don't know if it's because it's super early and I haven't had my coffee, or because your Jedi mind control actually *is* stronger, but I (for some reason) am in complete agreement with your proposal. It rocks. I will change my implementation right now. Should take ten minutes. This is all I ask. Don't change your &^%^&%ing mind again, and if you do don't tell us about it until after my conferences ;) Oh, and Clark; Nevermind... Cheers, Brian PS Get working on that spec. I'll be pointing a lot of people at yaml.org. |
From: Oren Ben-K. <or...@ri...> - 2001-07-19 15:04:25
|
Brian Ingerson [mailto:in...@tt...] wrote: > I don't know if it's because it's super early and I haven't > had my coffee, or > because your Jedi mind control actually *is* stronger, but I (for some > reason) am in complete agreement with your proposal. It rocks. :-) > I will change my implementation right now. Should take ten minutes. And I will draft this as a standalone spec this weekend. > This is all I ask. Don't change your &^%^&%ing mind again, > and if you do > don't tell us about it until after my conferences ;) I Promise :-) And good luck at the conference. > Cheers, Brian > > PS Get working on that spec. I'll be pointing a lot of people > at yaml.org. I'll be uploading the new spec on Sunday to yaml.sourceforge.net; Clark will need to mirror it on yaml.org. I guess you can point them to either place. Aside from the above agreement, there were other issues needed to be fixed in the spec: - I should probably merge it into a single spec now that we leave the APIs out (sigh). - Always bulleted lists - using ':' for scalars - are now in, right? - Null nodes should be added (I somehow forgot them last time). - Circular references should be banned. - Shortcut syntax for !class %format etc. - can I use the [ <color ] notation? - The Unicode vs. ISO 10646 issue. I would like to put wording to the effect that where it matters, YAML uses the Unicode way of doing things. I don't want us to get into all the messy differences between them; where there is a difference, it seems Unicode is what people actually use. Perhaps the best way would be to simply remove the references to ISO 10646. Also, there is the question of the particular character ranges Clark put in there - I'm rather uneasy about them. Clark, can you shed some light on this? - Should the status be changed to "release candidate 1", or just mark it as "unlikely to change"? - Anything else? Send me any other last-minute fixes you can think of... Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2001-07-19 17:51:34
|
Brian Ingerson [mailto:in...@tt...] wrote: > > - Always bulleted lists - using ':' for scalars - are now in, right? > > Correct. > > > - Null nodes should be added (I somehow forgot them last time). > > Using the '~' notation, correct? Right. > > - Circular references should be banned. > > Not from my standpoint. I really would like to leave them in. They're > important. Duplicate references are also extremely important. Duplicates are in. Clark asked to take circular references out... I'm neutral on this. Currently they are in. Clark? Have fun, Oren Ben-Kiki |
From: Brian I. <in...@tt...> - 2001-07-18 16:02:11
|
On 18/07/01 12:14 +0200, Oren Ben-Kiki wrote: > Brian Ingerson [mailto:in...@tt...] wrote: > > 1) No tabs allowed in indenting. It is invalid YAML. > > > > 2) All indenting is mandatory 4 spaces. > > We can live with that... Great! > > > 3) Blocks are represented like: > > > > foo: > > line 1 > > line 2 > > line 3 > > bar: - > > multi-line > > with no final new line > > Two issues: > > 1. It seems we can say there are only two formats, > "quoted" and "block". The "block" format uses the > syntax we initially used for "simple scalars", > including the single-line: > > foo: This is a block value! Disagree. This is a simple scalar which ignores leading and trailing whitespace and has no trailing newline. Same as: foo: "This is a block value!" or foo: This is a block value! or foo: "This is a block value!" so this is really a block value: foo: This is a block value! > > Quoted strings have escapes, are folded - in short, > they are "processed". "block" format is taken "as is", > without any special interpretation of the characters. > Very neat. Yes. Agree. > > 2. Using '-' to imply "no trailing newline". I think > we should use something else, to allow for: > > foo: -12.5 Right. I agree. I really only felt weakly about the '-', but threw it out there for comments. So thanks for jumping on it :) > > 3. Considering both (1) and (2), and assuming some > character X (say we use '\') is used to denote "no > trailing newline", then to encode a simple number > (say), one would have to write: > > foo: \1234 > > When we much rather be able to write: > > foo: 1234 But this is *not* a block. So there is no trailing newline. > > The cleanest syntactical way around this is to have > the default be "with trailing new line" for a multi-line > value and "without trailing newline" for a single-line > value. The indicator character would mean "reverse the > default": > > foo: without newline > bar: \with newline > baz: > with new line > boo: \ > without newline > > Clean, for sure. But also slightly confusing. Since bar and baz are the same, just eliminate bar. baz is not confusing. I am fully in favor of just replacing '-' with '\' from my previous proposal. Both in map and bulleted list context. Sound OK? > 4. How about we have an indicator for *having* the > trailing newline included? > > foo: without newline > bar: \with newline > baz: \ > with new line > boo: > without newline > > So most multi-line blocks would require the '\'... > Is this acceptable? bar can always be bar: "with newline\n" Switch the meaning for baz and boo. I think having a trailing newline is much more common. > > > baz: @ > > : > > Multi line block. > > Note (Oren) that the ':' is a > > bullet for blocks in list context. > > Joy! :-) Good. > > > 4) Top production is a list of maps, but the list > > separator is "---\n" instead of "\n". > > That makes it easier to include empty lines in blocks, > I guess. OK. Right. > > 5) Multi-line map keys may only be quoted (and possibly escaped). No > > block mode allowed. > > Why? > > map: % > unquoted key: value > "quoted key": value > multi > line key: value > > Where's the harm? Um. Blocks are verbatim. This is not verbatim. What if there were an actual ':' in the block? I don't think we need to argue this one. It's a rare case, and quoted w/ escaping can do everything we need. > > > These rules allow a very clean YAML, and make for very deterministic > > parsing. They eliminate the need for a closing '>>' or even a leading > > '<<' for blocks. They also simplify the heuristics for emitting. > > And give us just two scalar forms instead of three! Depending on what you call: foo: simple string with non-significant WS This is just the short form of: foo: "simple string with non-significant WS" Basically it boils down to: "Blocks always start on the next line". I think that's completely reasonable and obvious. > Question: what was the verdict about leading/trailing spaces? I think > we agreed to eliminate them completely in quoted strings. It seems that > leading/trailing spaces are also removed in the first line (the key line) > of a block value as well, because the <CR> in: > > foo:<CR> > value > > is stripped. So: > > foo: some value > > (note both leading and trailing space) is the same as: > > foo: some value > > Makes sense? > > > Thoughts? > > See the above. We may want to change the name "block" to "plain" (so we'll > have "quoted" and "plain" text). > > > FYI, I'm very comfortable with this syntax and will go ahead > > and use it for my demoes. Clark is currently in agreement as > > well. > > I really like this direction. Merging the "block" and "simple" text > formats into a single "plain" text format is neat. Let's just clear > up the issue of the with/out newlines indicator (definitely not '-') > and the trailing/leading spaces, and I'll roll out a release candidate > draft this weekend. So to recap: Just change '-' to '\'. Cheers, Brian |