From: Oren Ben-K. <or...@ri...> - 2001-06-12 14:28:17
|
Hi Guys, I didn't have time to really look into the API work you have been doing. I'll try to catch up. In the mean while, the new draft I promised is available at http://yaml.org/09jun2001.html. I tried to send it directly earlier but it got caught by an E-mail size limit somewhere. I hope you find it to be an improvement over the last one. There is a new "Changes" section where I listed those I did from the previous one and the list of changes yet to be done. The changes I put in are based on the agreements we made in this list, though I did make some (minor, I hope) changes to the indentation scheme. Double check me on this... A known issue with this draft (there's always one more) is that production 64 requires white space between a key and the ':', but all the examples don't have one. I think we should fix the production to make the white space optional. Finally, a notion in preparation to adding the color idiom into the draft. Clark wanted to be able to evolve a scalar to a list, and Brian's and my objection to this was that most of the time we'd want a list to map to a normal native list (which doesn't support the "have a default value" behavior). This objection can be overcome by somehow annotating such lists in a special way, e.g.: address: Single address Evolves to: address: @= Default address Additional address Since the file explicitly makes use of the "list with default value" construct, it is OK if it is implemented less efficiently via some extension/wrapping to the normal built-in list construct. Thoughts? Have fun, Oren Ben-Kiki |
From: Oren Ben-K. <or...@ri...> - 2001-11-03 23:36:28
Attachments:
04nov2001.zip
|
I just finished writing the new spec and am trying to upload it. Of course the computer crashed in the middle so my previous thought-out reply to the issues Brian raised has gone with the wind. There's something about the stability of computers and networks late at night... At any rate, given the hour I'm just posting the new draft (zipped, it is less then 30k). I've put the issues Brian raised in the "Probable Changes" section - it is too late (literaly) now here for me to deal with them. I'm going to be very busy tomorrow (Sunday is a work day here), so I'd appreciate it if one of you guys could upload the draft to the site (updating www.yaml.org wouldn't be a bad idea either, as would be updating the 'latest' link). I'll only have time to get to it on Monday earliest. Feedback is welcome as usual. I'd also love to hear what Paul Prescod has to say about YAML... Have fun, Oren Ben-Kiki |
From: Clark C . E. <cc...@cl...> - 2001-11-04 15:18:12
|
Thank you. This is nice. Updated both SF and YAML.ORG General comments... A. I like that the the "indicators" follow the "properties", it gives consistency between the quoted scalar and the block scalar -- the indicator ("|) follow the descriptor (&!) B. I'd still like to de-couple the "implicit syntax" with the type system. In particular, I'd like to be able to specify... picture: !gif [base64 encoded image] empty-map: !map ~ float: !float 0 To enable this, we must de-couple the type system from the implicit syntax mechanism. Changes: - Rename section 2.6 ("Syntax Modules"). Move the quoted scalar and block scalar into this section so that they can join the reference, numeric, etc. - In section 2.5.2 strike "This can be avoided by providing an explit type annotation". I'd like unquoted scalars not starting with an alphabetic character to be an error if an appropriate syntax module cannot be discovered. - Label each syntax module if it can participate as part of a key; yes/no - Keep the regex for each sytnax module. - Give a default type for each syntax module if the user has not explicity provided the type. This change has a few advantages: - It merges our "quoted" and |block syntaxes into a uniform mechanism with our other syntax variants. In this way, they are no longer exceptions. - It separates syntax from type (as it should) - It allows type overriding for a given syntax. - It throws an error when a syntax module for the given type cannot be found. A few nitpicks... 1. Production 31 and 32 (escape_in_*_quotes) should be normalized into three productions to separate out most of the escape sequences. 2. Production 47 (normalized_line_breaks) should be singluar normalized_line_break. 3. Throwaway comments... remove "sole purpose is to communicate among human mantainers". As I'm sure it will be (ab)used for many purposes, including the unix #!/my/func trick. 4. I didn't quite grok production 51... I'd make this production only match when an escape is used... ie, make the "escape?" "escape". Best, Clark On Sun, Nov 04, 2001 at 01:37:11AM +0200, Oren Ben-Kiki wrote: | | I just finished writing the new spec and am trying to upload it. Of course | the computer crashed in the middle so my previous thought-out reply to the | issues Brian raised has gone with the wind. There's something about the | stability of computers and networks late at night... | | At any rate, given the hour I'm just posting the new draft (zipped, it is | less then 30k). I've put the issues Brian raised in the "Probable Changes" | section - it is too late (literaly) now here for me to deal with them. | | I'm going to be very busy tomorrow (Sunday is a work day here), so I'd | appreciate it if one of you guys could upload the draft to the site | (updating www.yaml.org wouldn't be a bad idea either, as would be updating | the 'latest' link). I'll only have time to get to it on Monday earliest. | | Feedback is welcome as usual. I'd also love to hear what Paul Prescod has to | say about YAML... | | Have fun, | | Oren Ben-Kiki | |
From: Clark C . E. <cc...@cl...> - 2001-06-14 13:54:15
|
On Tue, Jun 12, 2001 at 04:28:48PM +0200, Oren Ben-Kiki wrote: | Clark wanted to be able to evolve a scalar to a list, and Brian's and my | objection to this was that most of the time we'd want a list to map to a | normal native list (which doesn't support the "have a default value" | behavior). This objection can be overcome by somehow annotating such lists | in a special way, e.g.: | | address: First address | | Evolves to: | | address: @= | First address | Additional address This as opposed to? address: @ First address Additional address I am curious what the difference between these would be? I was assuming that a asScalar() when called on the "@" node would return the first value. The asScalar() function would be at the parser level -- and perhaps built in as a external "friend" function that can work on any list or map. Thus... lists and maps load as a lists and maps respectively, unless the consumer asks for a scalar instead. asScalar() is *layered* over the underlying interface and need not be used directly. | Since the file explicitly makes use of the "list with default value" | construct, it is OK if it is implemented less efficiently via some | extension/wrapping to the normal built-in list construct. Thoughts? Hmm. This is interesting. I think I'll need some "implementation experience" before we should move in this direction (and even implementing asScalar... ) Thoughts? Best, Clark |