From: Tim P. <ti...@po...> - 2006-02-03 22:29:25
|
Clark C. Evans wrote: > A few clarifications; my send-trigger-finger got prematurely activated. > > On Fri, Feb 03, 2006 at 04:11:35PM -0500, Clark C. Evans wrote: > | Last week we had a brief conversation between Oren, Ingy and myself > | on the topic of JSON compatibility -- which I believe should be the > | limited scope for YAML 1.2; here are a few declarations to help set > | the direction for 1.2 activity: > | > | 1. Changes to the specification should first and formost include > | clarifications of trouble-spots from the past specification; > | ideally, listing those as a separate 1.1 Errata. > | > | 2. No new features will be included in YAML 1.2, the sole goal is to > | make YAML as compatible with JSON as possible; in particular, only > | the "in-flow" forms of constructs will be changed (other than > | corrections) since these productions are the ones relating to JSON. > | > | 3. Constructs in YAML which are valid JSON but have _different_ > | interpretation will become syntax errors. This implies that not > | all JSON will be valid YAML (unfortunately); a particular example > | of currently valid YAML that will become invalid: {"key":"value"} > > In JSON, {"key":"value"} is equivalent to { 'key': 'value' } > In YAML, {"key":"value"} is equivalent to { 'key:value': '' } > > There are a few other edge cases like this that we should make > illegal YAML; a different interpretation is seen as the _worst_ > case scenerio. > > | 4. I'd like to consider adding /* c-style */ comments to in-line YAML > | as these are valid JSON. > ^ Javscript > > This was a typo, sorry. JSON does not support /* -- */ nor // > style comments; unfortunately, I've seen many documents which > claim to be JSON that included /* c-style */ comments; so I > thought we could at least consider using these comments in > the very limited scope of our JSON-like sub-syntax.. > > | 5. Any further changes needed to harmonize YAML /w Javascript or > | reduce the chance of error when using JSON in the context of > | a YAML processor. In particular, we will consider making illegal > | things which are valid Javascript (but illegal JSON) that happen > | to also be YAML, but with a different meaning. > | > | Kind Regards, > | > | Clark > | > | > | ------------------------------------------------------- > | This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > | for problems? Stop! Download the new AJAX search engine that makes > | searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > | http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > | _______________________________________________ > | Yaml-core mailing list > | Yam...@li... > | https://lists.sourceforge.net/lists/listinfo/yaml-core > > I hope I'm not offending anyone if I suggest that a suitable goal for yaml is to simplify the language a little to help people write parsers for it? It's been pointed out many times that the spec really overcomplicates things for developers. If there was a suitable way of writing a preparser to handle some of the context sensitive nature of the grammar and then a standard production set that could handle the remainder I think a lot of people would have started using yaml. Syck seems to be (correct me if I'm wrong) pretty much the de-factor yaml standard implementation. I don't want to break yaml, but I really think there is a space for a yaml-lite that sits somewhere the current spec and json; Allowing all the ease of use and flexibility without the 'special cases' that I don't think add to the predictability of the grammar. I'd be happy to help on this as I've felt the pain of trying to develop a production based grammar myself. I'd be interested in peoples opinions in the matter and I hope I'm not offending anybody; I think yaml is great and we're using it in pretty much every we do, I just think it could be so much more. 'hope I'm not being to honest'ly yours Tim |