[Yaml-core] Re: JSON and YAML - a minor incompatibility

[Clark C. E. <cc...@cl...>]

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