Matthew,

Have you seen the JSYNC proposal I made last month? http://www.jsync.org

I think it covers what you are trying to accomplish here, and even resolves your caveats. It provides everything that you can do in YAML, using standard JSON encoding.

Want to help me with it?

Cheers, Ingy


On Tue, Jun 8, 2010 at 3:22 AM, Matthew Willson <matthew.willson@gmail.com> wrote:
Dear all

Thought I would pop up on this list to sound out people's feelings about the following proposal.

Motivation:

* YAML syntax is quite big and complex to fully support
* No full YAML parser appears to exist for browser Javascript clients
* Web browsers have fast, native JSON parsers which it's nice to use where possible
* Plain JSON lacks custom data types and graph-based serialization features
* People are reinventing the wheel trying to add these things on top of JSON in assorted poorly-standardised ways
* YAML and JSON are already friendly, this would make them friendlier still :)

Proposed solution is an embedding of YAML inside JSON, which could be implemented as an alternative presentation phase for a YAML library. The goal is that:

* Data which would happily serialize as plain JSON, maps directly to its plain JSON representation (with the exception of some reserved key names required for the embedding)
* Data which is not pure-JSON-compatible (uses types other than map,seq,string,int,float,null, or does not conform to a simple tree structure, containing cyclic references for example) maps to a subset of JSON from which the original YAML node tree can be recovered.

Available cheesy name: Yayson. Sorted.

I'm sure I'm missing some subtleties, but here's an outline of how this could be achieved. First tags:

{
"$tag": "!!timestamp",
"$value": "2001-12-15T02:59:43.1Z"
}

{
"$tag":  "!my-app-specific-type",
"$value": {"is constructed from": "a map"},
}

Or a more concise alternative syntax for this:

{
"$tag":  "!my-app-specific-type",
"is constructed from": "a map"
}

(I would suggest that full support for things like tag namespace aliases via the %TAG directive not be supported here, to keep it simple; ! and !! could have their usual meanings as tag prefixes, or you could use a full tag URI)

Now anchors:

{
"$anchor": "foo",
"$value": "some string"
}

{
"$anchor": "foo",
"$tag":    "!!timestamp",
"$value":  "2001-12-15T02:59:43.1Z"
}

{
"$anchor": "foo",
"$value": {"anchor is for": "a map"},
}

or the alternative in the case of a map:

{
"$anchor": "foo",
"anchor is for": "a map"
}

Now aliases:

{"$alias": "foo"}

Some caveats:

This introduces 4 'reserved' key names for maps. Plain JSON data containing these keys would not actually be able to serialize in the usual way; they'd need to be escaped, via eg:

{"$$anchor": "the key unescapes to $anchor"}
{"$$$anchor": "the key unescapes to $$anchor"}
..

Some more special forms may be needed to express some other YAML features (like arbitary objects as keys of maps) not expressible in JSON, eg:

{
"$tag": "!!map",
"$pairs": [
 [{"key": "object"}, {"value": "object"}],
 [{"other key": "object"}, {"value": "object"}]
]
}

Anyway let me know what you think!

-Matt
------------------------------------------------------------------------------
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
_______________________________________________
Yaml-core mailing list
Yaml-core@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yaml-core