The most important serialisation format to work together is JSON, since it is an RFC standard that is widely used within internet services. Also JSON parsers is widely supported for many languages. A reason for it's popularity, is the simplicity of the syntax, and the speed and size of the parsers that reads it.

These properties of JSON, makes it widely popular as an embedded parser for human readable settings.

While JSON is a subset of YAML in terms of the data models, and datatypes... the reverse does not hold true. This leads to two distinct requirements that may differ between projects.

Some coders will require a parser that can convert YAML to JSON to YAML without any loss of information or comments.

Other coders will require a parser that can convert YAML to JSON in the most transparent manner, and do not mind the loss of information.

These two approaches to consider is "Type Preservers" and "Type Strippers/Transformer".

YAML2 would do well to illustrate both approaches.

Type Preservers

Much like how an interpreter deals with type. To ensure that type information is not lost between conversion, every entry has it's datatype defined. As shown above in "# Serialize types as objects" section."

Type of content is accessed like "foo.type", and content accessible depending on type (e.g. foo.string).

Pros: Minimal loss of information when converting back and forth. Cons: Parser will be larger/slower

e.g.

{
    "foo": { 
				"type":"!bar",  
				"content": "baz"
			}
	,
    "fooMany": 	[ 
					{ 
						"type":"!bar",  
						"content": "baz"
					}
					,
					{ 
						"type":"!bar",  
						"content": "baz"
					}
					,
					{ 
						"type":"!bar",  
						"content": "baz"
					}				
				]
}

edit: JSYNC appears to be a specification that could potentially provide a lossless YAML to JSON encoding method. http://jsync.org/ . If this works, then just recommend this.

Type Strippers/Transformer

Unlike "Standard YAML to JSON", which aims to avoid losing type information, this specifically will throw out any entries that is not natively supported in json. ( But maybe also add recommendations for converting date or binary types to "ISO 8601 - datetime scheme" and "rfc2397 - data url scheme" )

Pro: More compact serialization. Minimal modification to most codes using json already. Parser is smaller/faster Cons: Loss of models/type information that doesn't exist in JSON.

e.g.

{
	"foo" : "baz",
	"fooMany" : [ "baz", "baz", "baz" ]
}