From: Clark C. E. <cc...@cl...> - 2005-11-13 19:11:15
|
Douglas, I wanted to thank you so much for you kind words about YAML and for your mindfulness. Since I first looked at the JSON spec on your web page, you've made several substantial changes: 1. You no longer have the 'name' production 2. You removed /* comments */ 3. You removed single-quoted strings (which have a different interpretation than double-quoted in YAML) I'm absolutely thrilled about these changes: JSON is the simple "canonical" subset of YAML (for minimalists) that I've been wanting. I have enthusiastically adopted JSON in my own AJAX development when communicating /w web browser clients. It is fantastic. That said, I think there is at least one more incompatibility that we have: Currently in YAML, the key/value separator ": " and the element separator ", " include a single whitespace character; this extra space is not required by JSON. Hence, not all JSON files will be parsed correctly by a fully-compliant YAML processor. It is an edge case, but a particularly ugly one. The rationale for this decision was to allow for unquoted currency, such as "3,459,129.00" to include commas for readability but not require quotes. I have thousands of YAML documents /w business transaction and accounting records using this feature, and the readability is very very nice. The rationale for ": " was more for consistency, but happens to allow Perl identifiers to be unquoted in YAML files. In any case, this incompatibility should be addressed; and I can think off-hand of a few ways to fix it: Either JSON is updated to require that a whitespace character (0x20, 0x09, 0x0A, 0x0D) be added to the ":" and "," production. Or, YAML is updated to not require this space -- consequently dropping support for unquoted currency and Perl identifiers (at least in the JSON compatible in-line forms). I'm not sure what the deployment impacts of these alternatives would be. If it is not too difficult to change JSON, great (i.e. if all JSON producers already include that space). However, I very much like the JSON specification's simplicity -- and I'd like it to remain simple. So, if this production restriction makes things more complicated, then the 'cruft' to deal with this incompatibility properly belongs in YAML land, not in JSON's domain. At this point, I'm thinking hard about how we can patch the YAML specification so that this minor but important incompatibility goes away. Your feedback, of course, is very welcome. Kind Regards, Clark Evans P.S. I am also thinking of updating the YAML specification to present JSON as a proper subset; do you mind me stealing some of your material (as necessary) for inclusion in the YAML specification? |
From: why t. l. s. <yam...@wh...> - 2005-11-13 22:28:55
|
Clark C. Evans wrote: >P.S. I am also thinking of updating the YAML specification to present >JSON as a proper subset; do you mind me stealing some of your material >(as necessary) for inclusion in the YAML specification? > > Ah, peace among mankind. Such a glorious feeling. The hand of Clark C. Evans stretches across the nations... The next version of Syck will have a JSON output mode, similar to the mode it currently has for outputing inlines. _why |
From: Clark C. E. <cc...@cl...> - 2005-11-13 23:57:57
|
Douglas, I would also be relucant to make any changes to JSON; it is quite a simple and beautyful notation. We will see what can be done on the YAML side of this particular concern so that it does not cause our shared user base unexpected results. Kind Regards, Clark On Sun, Nov 13, 2005 at 12:37:07PM -0800, Douglas Crockford wrote: | Thank you very much, Clark. | | I understand your concern. One of the motivations for dropping | comments was to make life easier for YAML. | | Some JSON encoders include spaces after colon and comma, but most | don't because they want to minimize payload size. Of course, all | encoders must tolerate the spaces. | | I am really reluctant to make any more changes to JSON. In particular, | giving significance to whitespace, given JSON's C ancestry, feels wrong. | | You certainly have my permission to use or adapt any of the JSON | material. The Visio file for the diagrams is at | www.crockford.com/JSON/json.vsd | | Clark C. Evans wrote: | >Douglas, | > | >I wanted to thank you so much for you kind words about YAML and for your | >mindfulness. Since I first looked at the JSON spec on your web page, | >you've made several substantial changes: | > | > 1. You no longer have the 'name' production | > 2. You removed /* comments */ | > 3. You removed single-quoted strings (which have | > a different interpretation than double-quoted in YAML) | > | >I'm absolutely thrilled about these changes: JSON is the simple | >"canonical" subset of YAML (for minimalists) that I've been wanting. | >I have enthusiastically adopted JSON in my own AJAX development when | >communicating /w web browser clients. It is fantastic. | > | >That said, I think there is at least one more incompatibility that | >we have: | > | > Currently in YAML, the key/value separator ": " and the element | > separator ", " include a single whitespace character; this extra space | > is not required by JSON. Hence, not all JSON files will be parsed | > correctly by a fully-compliant YAML processor. It is an edge | > case, but a particularly ugly one. | > | >The rationale for this decision was to allow for unquoted currency, such | >as "3,459,129.00" to include commas for readability but not require | >quotes. I have thousands of YAML documents /w business transaction and | >accounting records using this feature, and the readability is very very | >nice. The rationale for ": " was more for consistency, but happens to | >allow Perl identifiers to be unquoted in YAML files. In any case, this | >incompatibility should be addressed; and I can think off-hand of a few | >ways to fix it: | > | > Either JSON is updated to require that a whitespace character (0x20, | > 0x09, 0x0A, 0x0D) be added to the ":" and "," production. Or, YAML is | > updated to not require this space -- consequently dropping support for | > unquoted currency and Perl identifiers (at least in the JSON | > compatible in-line forms). | > | >I'm not sure what the deployment impacts of these alternatives would be. | >If it is not too difficult to change JSON, great (i.e. if all JSON | >producers already include that space). However, I very much like the | >JSON specification's simplicity -- and I'd like it to remain simple. So, | >if this production restriction makes things more complicated, then the | >'cruft' to deal with this incompatibility properly belongs in YAML land, | >not in JSON's domain. At this point, I'm thinking hard about how we | >can patch the YAML specification so that this minor but important | >incompatibility goes away. Your feedback, of course, is very welcome. | > | >Kind Regards, | > | >Clark Evans | > | >P.S. I am also thinking of updating the YAML specification to present | >JSON as a proper subset; do you mind me stealing some of your material | >(as necessary) for inclusion in the YAML specification? | > | > | |
From: Clark C. E. <cc...@cl...> - 2005-12-02 17:26:45
|
On Fri, Dec 02, 2005 at 05:31:47AM -0800, Douglas Crockford wrote: | How are you doing with the ', ' problem? I've been hammered /w day job work lately; so I've made sparse progress. This is going to be a bit tough -- not with ", " but with ": ". Quite a few existing Perl serializations use Package::Module items without quoting; by contrast only a few documents use unquoted values like 3,493. I think there is hope, however, since these existing serializations mostly use the indented, aka "block" style. I think we can bring consistency by forbidding the comma and colon in unquoted values found in the in-line style; but still admitting them in the more verbose indented style. This should get us JSON compatibility without huge amount of existing document breakage. However, it will (as such things typically do) complicate the productions even more. Fun. On the very positive side, Why has gracefully hinted that he'd make any necessary changes in his implementation, Syck. Then it is a matter of getting the other implementations on-board. Best, Clark |