From: Brian I. <in...@tt...> - 2001-10-26 01:01:38
|
First, thanks for all the hard work you guys. I agree with Clark that we are very close. I'll try to finish this off. Here goes: > To summarize: > 0. Let's get rid of '@' and '%' as my original proposal. OK. I really wish there was a more elegant solution for expressing empty maps and lists, but it eludes us. :( > 1. Please don't use ':' instead of ' ' to separate "descriptors". OK > 2. We can use ':' instead of '\' as the next-line scalar indicator (though > I'd rather keep '\'). Here is what I want: inline quoted: '"See Clark, double quotes are OK for starting", said Brian gleefully!' inline unquoted: -42 nextline quoted:: "You say you want a revolution?" nextline unquoted:: multi line (tabs rock :) block:| sub foo { print "Hello YAML!\n"; } chomp:|- sub bar { print "Goodbye backslash!\n"; } B > 3. Let's keep '~' as an implicit type - not a descriptor. Likewise for > '*<anchor>'. OK. > 4. We can add in-line block values (I've no strong opinion). NO! I mean, "I'd rather not". > 5. Let's use '-' instead of ':' for list entries (unless someone feels > strongly against it). OK > 6. Let's have explicit type names available for text as well as map and > list. OK > 7. Let's keep the special type names as '<type>!' instead of '.<type>'. Defer to you guys. > 8. We can add a '^<index>' descriptor for sparse lists (I've no strong > opinion). I like '@'. is it list: -@12 twelve or list: - @12 twelve or both? > 9. We can restrict unquoted keys to one line (I've no strong opinion). OK > 10. There's no need for a magical empty map/list descriptor beyond the > explicit map/list type name. OK :( > 11. Let's have an *optional* central registry for implicit types. Defer. As long as we have implicit types, I'm cool. > 12. There's no need to be able to serialize the ! and & keys. OK. But we still use the internal trick to round trip data. Right? > 13. We can have multiple line breaks indicate a top-level list (though I'd > rather use a list syntax). Two points. A) This is not a 'list' in the YAML sense of 'list'. (A YAML 'list' is really an 'array' in almost all language lingo.) This is a series of top level YAML nodes. BTW, this is a common idiom in all Perl serialization modules. So I am completely against the 'list' syntax. B) I can't quite argue away Clark's logic about blank lines. So let's go with /(^---\s*$)+/. That means: --- --- "Leading, trailing and consecutive separators are ignored. I think top level scalars must be quoted if not indented, to avoid confusion, lookahead problems, etc. It also allows for easier reserved functionality like comments." --- : Or unquoted and indented is OK too --- |- Blocks as well --- map: foo bar:: "YAML, YAML, YAML" --- - list item 1 - item 2 -: "item 3" -|- i t e m 4 -@12: item 12 --- --- "The following production is an empty string" --- "" that the above document contains a series of 7 YAML productions. > 14. Let's reconsider using tabs for indentation. YES! > 15. Let's not have a special in-line key/value pair syntax for '#'. OK > 16. Let's consider having throw-away comments and other filters as > "transfer encoding". I like the standard library approach: $YAML::StripComments = 1; my @series = YAML->thaw('file.yaml'); But, whatever you guys feel is appropriate is fine. That said, I'll most likely put a comment stripping option in my Perl implementation. > 17. Let's not have a next-line form for the quoted > scalar, so that the multi-line scalar is simpler. I agree with the latest logic on this (which is "disagree" :). But I also want to allow single quotes to work the same as double quotes, so that a string can start with either. > 18. Let's allow for multi-line scalars to begin on > the first line and extend to further lines, eg. Yes. Of course. But not for blocks, of course. 19. Let's consider changing the term 'list' to 'array' in all YAML documentation. That's it. Nothing major. Nothing we haven't seen before. Can we have Oren do another spec? Cheers, Brian |
From: Brian I. <in...@tt...> - 2001-10-26 04:44:01
|
I was bored and decided to give Clark a call on the phone. We found a couple things. I'll share my ideas, and I'm sure Clark will share his. On 25/10/01 18:01 -0700, Brian Ingerson wrote: > First, thanks for all the hard work you guys. I agree with Clark that we > are very close. I'll try to finish this off. Here goes: > > > To summarize: > > 0. Let's get rid of '@' and '%' as my original proposal. > > OK. > > I really wish there was a more elegant solution for expressing empty > maps and lists, but it eludes us. :( Pesky bugger! I'm not sure we can get rid of '@' and '%'. What if a classed thing is also an empty array? How do we serialize? Options: one: !.Foo @ two: !.Foo !array Hmm. Well we have two classes here, but in reality one of them is a type. Perhaps that's OK. Are all !org.yaml.core.foo (!foo) classes, actually types? Thoughts? > > 2. We can use ':' instead of '\' as the next-line scalar indicator (though > > I'd rather keep '\'). > > Here is what I want: > > inline quoted: '"See Clark, double quotes are OK for starting", > said Brian gleefully!' I realized that although you can do this, Clark's point still stands that you can't start an unquoted scalar with a quote. I'm fine with that. I think everyone is. > > 5. Let's use '-' instead of ':' for list entries (unless someone feels > > strongly against it). At least for the time being. Time will tell whether or not this is pleasing. > > 7. Let's keep the special type names as '<type>!' instead of '.<type>'. > Defer to you guys. I now switch my opinion to my other email, where I list 4 types of classes. > > 8. We can add a '^<index>' descriptor for sparse lists (I've no strong > > opinion). > > I like '@'. I also like [42]. If we want to be more cautious with '@', we could try that. list: - zero -[42] forty-two Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2001-10-26 05:01:22
|
| > I really wish there was a more elegant solution for expressing empty | > maps and lists, but it eludes us. :( | | Pesky bugger! | | I'm not sure we can get rid of '@' and '%'. What if a classed thing is also | an empty array? How do we serialize? Options: | | one: !.Foo @ | two: !.Foo !array | | Hmm. Well we have two classes here, but in reality one of them is a type. | Perhaps that's OK. Are all !org.yaml.core.foo (!foo) classes, actually types? | | Thoughts? Definately pesky -- there is a difference between "kind" and "type". We could solve it, of course, by bringing in back our two indicators (@) and (%). That may be the only solution. | > > 5. Let's use '-' instead of ':' for list entries (unless someone feels | > > strongly against it). | | At least for the time being. Time will tell whether or not this is | pleasing. My only concern had to do with lists of numbers... list: - 3 - -4 - 5 | > > 8. We can add a '^<index>' descriptor for sparse lists (I've no strong | > > opinion). | > | > I like '@'. | | I also like [42]. If we want to be more cautious with '@', we could try that. | | list: | - zero | -[42] forty-two This kinda breaks our "indicator" approach, i.e. option = indicator data white-space let us try: - zero -42 forty-two or-perhaps: : zero :42: forty-two I think this may be an argument to "keep" the : as the list indicator. Best, Clark |
From: Clark C . E. <cc...@cl...> - 2001-10-26 04:53:22
|
On Thu, Oct 25, 2001 at 06:01:33PM -0700, Brian Ingerson wrote: | > 2. We can use ':' instead of '\' as the next-line scalar indicator (though | > I'd rather keep '\'). 1. So :: is a next-line scalar. 2. Quoting can be with either " or ' 3. nextline unquoted can't start with a quote. 4. Using |- for chomp. Ok. | > 4. We can add in-line block values (I've no strong opinion). | | NO! I mean, "I'd rather not". Ok. | > 5. Let's use '-' instead of ':' for list entries (unless someone feels | > strongly against it). | | OK Ok. Let's tentatively set it as a dash then, we can change it back to a colon if we find it problematic. | > 7. Let's keep the special type names as '<type>!' instead of '.<type>'. | | Defer to you guys. You cover this in your #22, let's defer till there. | > 8. We can add a '^<index>' descriptor for sparse lists | (I've no strong opinion). | | I like '@'. | | is it | | list: | -@12 twelve | | or | | list: | - @12 twelve | | or both? I like the first, but the second is more consistent with using whitespace as the delimiter... | > 9. We can restrict unquoted keys to one line (I've no strong opinion). | | OK Ok. | | > 10. There's no need for a magical empty map/list descriptor beyond the | > explicit map/list type name. | | OK :( Let's keep this as an "open issue" for now, but still move forward. The problem is representing a empty blessed map in perl. You can have one or the other, but not both. This may cause us to bring back the (%) map indicator *sigh* the-map: !map the-class: !class | > 11. Let's have an *optional* central registry for implicit types. | | Defer. As long as we have implicit types, I'm cool. Good deal. Oren and I will dream up some language for this. | > 12. There's no need to be able to serialize the ! and & keys. | | OK. But we still use the internal trick to round trip data. Right? IMHO, each language binding will have to worry about round-tripping explicit types that it doesn't handle natively. How it does this is probably best done in the context of the language itself... given that the serialization language won't be impacted. An example, would be promoting a scalar to a map with special keys. In any case, the implemetation should offer a warning when ever this sort of condition appears. | > 13. We can have multiple line breaks indicate a top-level list (though I'd | > rather use a list syntax). I agree with Brian's use of three dashes (---) for a separator. His examples make sense. | > 14. Let's reconsider using tabs for indentation. | | YES! Ok. | > 15. Let's not have a special in-line key/value pair syntax for '#'. | | OK Ok. | > 16. Let's consider having throw-away comments and other filters as | > "transfer encoding". | | I like the standard library approach: | | $YAML::StripComments = 1; | my @series = YAML->thaw('file.yaml'); | | But, whatever you guys feel is appropriate is fine. That said, I'll most | likely put a comment stripping option in my Perl implementation. Ok. As long as the API does not strip comments by default; i.e. it requires developer interaction to change the default. | > 17. Let's not have a next-line form for the quoted | > scalar, so that the multi-line scalar is simpler. | | I agree with the latest logic on this (which is "disagree" :). But I | also want to allow single quotes to work the same as double quotes, so | that a string can start with either. Ok. I can live with this decision, and it seems consistent. However, note that you can't have a un-quoted, non-block scalar that begins with a single or double quote. | > 18. Let's allow for multi-line scalars to begin on | > the first line and extend to further lines, eg. | | Yes. Of course. But not for blocks, of course. Ok. | 19. Let's consider changing the term 'list' to 'array' in all YAML | documentation. Ok. | 20. Reserve '=' for implicit tuple. Reserve !tuple as well. I don't think reserving '=' is required, but I will live with it. The following is just fine and works well for python people. | tuple: !tuple | - foo | - bar | 20a. I assume we are completely rid of: | | foo: !class | =: value | | Since that is easily represented as: | | foo: !class : | value Yes. | 21) I think the type indicator should immediately follow | the colon or dash, Ok. | regular string:: | regular string:: | "Hello YAML" | anchored string:: &005 | "Howdy YAML" | classed block:|- !my.text | Y | A | M | L | 22) Let's use the following classnames: | - !com.FatPort.foo "Explicit - fully qualified" | - !2.bar.baz "Relative - 'com.FatPort.bar.baz'" | - !.My.Class "Private - unregistered" | - !date "Reserved - for YAML types" Let's work through this one. I snipped your rationale. A few items: 1. The "relative" .Class mechanism works very well if you look up the ancestor tree for the first DNS based class that is not-relative. Pop the right most class, and then append the core class. Example: parent: !org.clarkevans.Timesheet hours: !.Person is equivalent to.. parent: !org.clarkevans.Timesheet hours: !org.clarkevans.Person One would rarely want to go up more than one level. And if so, the full explicit class mechanism is available. 2. For a yaml type "type", we could just use fully qualified YAML names: org.yaml.type And... for a common short-hand we can specify that there is an implicit "fixed" base of "org.yaml." so that the relative ".type" means "org.yaml.type" unless there is an absolute DNS based class in it's ancestor chain. Thus... one: !.tuple - one - !com.clarkevans.bing val: !.tuple - two date: 2001-11-01 spec: !org.yaml.BigInt 345 Is equivalent to... one: !org.yaml.tuple - one - !com.clarkevans.bing val: !org.clarkevans.tuple - twp date: !org.yaml.date 2001-11-01 spec: !org.yaml.BigInt 345 This is a simple mechanism where the fully qualified YAML is rather rare. 3. The last class "private" is any class without a period. Thus: !Data::Dumper ~ And:: !private bla bla bla Alternatively... We can use !type for all yaml types and then use a double exclamation !! for private types. | 23) Class names are case-sensitive. Any part of the name that is a | real domainname *should* always be specified in lower case. Yes. Clark |
From: Brian I. <in...@tt...> - 2001-10-26 05:17:35
|
On 26/10/01 01:03 -0400, Clark C . Evans wrote: > On Thu, Oct 25, 2001 at 06:01:33PM -0700, Brian Ingerson wrote: > | 22) Let's use the following classnames: > | - !com.FatPort.foo "Explicit - fully qualified" > | - !2.bar.baz "Relative - 'com.FatPort.bar.baz'" > | - !.My.Class "Private - unregistered" > | - !date "Reserved - for YAML types" > > Let's work through this one. I snipped your > rationale. A few items: > > 1. The "relative" .Class mechanism works very > well if you look up the ancestor tree for > the first DNS based class that is not-relative. > Pop the right most class, and then append the > core class. Example: > > parent: !org.clarkevans.Timesheet > hours: !.Person > > is equivalent to.. > > parent: !org.clarkevans.Timesheet > hours: !org.clarkevans.Person > > One would rarely want to go up more than > one level. And if so, the full explicit > class mechanism is available. > > 2. For a yaml type "type", we could just use > fully qualified YAML names: org.yaml.type > > And... for a common short-hand we can specify > that there is an implicit "fixed" base > of "org.yaml." so that the relative ".type" > means "org.yaml.type" unless there is an > absolute DNS based class in it's ancestor > chain. > > Thus... > > one: !.tuple > - one > - !com.clarkevans.bing > val: !.tuple > - two > date: 2001-11-01 > spec: !org.yaml.BigInt 345 > > Is equivalent to... > > one: !org.yaml.tuple > - one > - !com.clarkevans.bing > val: !org.clarkevans.tuple > - twp > date: !org.yaml.date 2001-11-01 > spec: !org.yaml.BigInt 345 > > This is a simple mechanism where the fully > qualified YAML is rather rare. > > 3. The last class "private" is any class without a period. > Thus: !Data::Dumper ~ > And:: !private > bla bla bla > > Alternatively... > > We can use !type for all yaml types and then use > a double exclamation !! for private types. Compromise: Relative: !.foo.bar # means !org.yaml.foo.bar Explicit: !org.hellzapoppin.foo.bar Relative: !.moo # means !org.hellzapoppin.foo.moo Relative: !.moo.mar # means !org.hellzapoppin.moo.mar Relative: !..mar # means !org.hellzapoppin.mar Reserved: !date # means !org.yaml.date Private: !!Data::Dumper Cheers, Brian |
From: Clark C . E. <cc...@cl...> - 2001-10-26 05:39:57
|
On Thu, Oct 25, 2001 at 10:17:28PM -0700, Brian Ingerson wrote: | Relative: !.foo.bar # means !org.yaml.foo.bar | Explicit: !org.hellzapoppin.foo.bar | Relative: !.moo # means !org.hellzapoppin.foo.moo | Relative: !.moo.mar # means !org.hellzapoppin.moo.mar | Relative: !..mar # means !org.hellzapoppin.mar | Reserved: !date # means !org.yaml.date | Private: !!Data::Dumper Great. I like the ".." thingy, nicely done. Let's talk abit about scope. First, you look "up" in the tree, if none found, then you look "back". Explicit: org.foo.bar child: .bar # org.foo.bar another: .bam # org.foo.bam subord: org.zzz.yyy child: .xxx # org.zzz.xxx child: .bar # org.foo.bar more: still: .baz # org.foo.baz Implicit: .zoom # org.foo.zoom child: org.aaa.bbb grand: .ccc # org.aaa.ccc more: .boogle # org.foo.boogle Ok? Clark |