From: Oren Ben-K. <or...@ri...> - 2002-05-17 14:50:00
|
I'm finally starting to work on the next draft. There are two issues which came to me when I did a quick overview of things: 1. In-line comments. Currently comments are only valid in a line of their own. However, when writing YAML text by hand I often get the urge to place a comment at the end of the line, and this isn't a problem almost everywhere. Today: # Comment line in-line: # error, not comment - "quoted" # error again - simple # value, not comment - ] # error again Value, not # a comment How about: # Comment line in-line: # comment, not error - "quoted" # comment again - simple # comment after simple - ] # comment again Value, not # comment 2. Boolean type. For some reason we left this out. If we consider configuration files to be an important use case, I think that such a type family is important enough to be included. Regardless of whether it should be in the spec itself or should be added later in yaml.org, there still remains the issue of what would be the best way to represent it. I thought something along the following lines would do: # Type family: !bool true values: - $true # canonical - !bool $TRUE - $True false values: - $false # canonical - $FALSE - !bool $False I couldn't think of a good non-English way to do this, and using just "true" or "false" without some non-letter character isn't an option. So I put a leading '$' to indicate "value". This may be a generaly useful tactic when implementing "enum" types. Thoughts? Have fun, Oren Ben-Kiki |
From: Neil W. <neilw@ActiveState.com> - 2002-05-17 16:38:08
|
Oren Ben-Kiki [17/05/02 10:51 -0400]: > I'm finally starting to work on the next draft. There are two issues which > came to me when I did a quick overview of things: > > 1. In-line comments. > > How about: > # Comment line > in-line: # comment, not error > - "quoted" # comment again > - simple # comment after simple > - ] # comment again > Value, not > # comment I see no problem with this. > 2. Boolean type. > > For some reason we left this out. If we consider configuration files to be > an important use case, I think that such a type family is important enough > to be included. > > Regardless of whether it should be in the spec itself or should be added > later in yaml.org, there still remains the issue of what would be the best > way to represent it. What's wrong with true values: - !bool 1 # or !bool true - !bool 0 # or !bool false ? > I couldn't think of a good non-English way to do this, and using just "true" > or "false" without some non-letter character isn't an option. Why not? I hardly think it's a stretch to assume that a value whose only letters are `t r u e' or `f a l s e' is a boolean. Later, Neil |
From: Clark C . E. <cc...@cl...> - 2002-05-17 17:01:30
|
| > 1. In-line comments. | | I see no problem with this. --- people: - &01 given: Clark family: Evans ... tasks: - caption: A task several pages later. owner: *01 # Evans, Clark ... This would increase readability in my dumps... | > 2. Boolean type. !bool 1 !bool 0 works for me... |