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. |