Re: Yayson (proposal for a YAML presentation embedded within JSON for browser clients)

Ingy dot Net wrote:

> "!!timestamp 2001-12-15T02:59:43.1Z"

I do not like this at all, because now you have to make up rules for how 
the value is quoted and you need to implement a nested parser for this. 
Leading spaces? Quotes in it? Backslashes in it? In fact you might as 
well just put the entire YAML file into one quoted string and call that 
a solution. I think any real solution has to split things into the final 
units at the JSON level, with the only post-processing the removal of 
single bytes from the starts of returned strings.

MY PROPOSAL FOR JYAML:

A value with an anchor:
	["&anchor", <value>]

A value with a tag (the %XX syntax is decoded so !!a%20b is written as 
"!!a b"):
	["!tag", <value>]

A value with both an anchor and tag:

	["&anchor", "!tag", <value>]
or
	["!tag", "&anchor", <value>]

A value that is a reference:

	"*anchor"

A map entry with a key that is a string with no tag or anchor:

	"key": <value>

A map entry with a key that is a reference:

	"*anchor": <value>

A map entry where the key is any object, including numbers, null, true, 
false, arrays, maps, and values with anchors or tags. Here 'A' is a 
string generated by the converter that does not conflict with any other 
anchors (note that parser can distinguish these anchors because they are 
declared as keys, not as part of an array value):

	# YAML: <key>: <value>
	"&A": <key>,
	"*A": <value>

All string values that start with 1 or more '.' characters followed by 
any one of '&*!@' have a single '.' removed to get the actual value:

	".!foo" -> "!foo"
	"...!foo" -> "..!foo"
	".1" -> ".1" # NOTE NO CHANGE!
	"..." -> "..." # AGAIN NO CHANGE!

Errors: Strings starting with '&' or '!' at unexpected places are an 
error. Strings starting with '@' are always an error. Arrays containing 
strings starting with '&' or '!' must conform to one of the patterns 
above, otherwise they are an error.

>     I guess the ultimate awkward corner case would be:
> 
>     A tagged custom type, which is also given an anchor, and which is
>     created from a map with some non-string keys and some
>     (suitably-escaped) reserved keys.
>
> --- !custom &anchor
> 55: I can't drive
> awesome: '!!!'

  ["!custom", "&anchor",
   {"&1": 55,
    "*1": "I can't drive",
    "awesome": ".!!!"
   }
  ]

>     Also, I guess an alternative approach (or perhaps one which is
>     undertaken in parallel?) would be to propose an extension to json
>     with new syntax for references and tags, to match the YAML model,
>     but only the minimal extra syntax required to do so, with the goal
>     of keeping it as easy to parse as possible.

This *IS* YAML. It's just that only the "flow" subset is being used. 
There is no need to define a different type.

I do agree this is useful and am using it myself. Unfortunately YAML's 
syntax has not lived up to expectations, in particular it is NOT 
hand-editable as soon as complex nested data, and text with newlines in 
it, are introduced. Mistakes in editing produce cryptic error messages 
or complete mangling of the data. I switched to "flow" all the time and 
modified libyaml to add newlines after the commas.

I also had to change the quoting rules to require that strings 
containing a '\' or '"' be quoted. This is because code assumed it could 
  take YAML output, throw away the optional surrounding quotes, and add 
them again later. This made YAML a useful presentation form, but only if 
these characters were always shown as "\\" and "\"".

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo