On Tue, Jun 8, 2010 at 3:05 PM, Matthew Willson <matthew.willson@gmail.com> wrote:
> Have you seen the JSYNC proposal I made last month? http://www.jsync.org

Aha, yeah that's exactly what I wanted! and a more concise syntax than mine.

I did google for something along these lines ("yaml inside json", etc) but nothing showed up, apologies for the dup :)

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

Great!

There's a few cases which the webpage doesn't include in its examples:

That page was just to give a rough idea of what was going on. I didn't want to scare people away with all the niggly details, on first glimpse. When I write the spec, it will cover everything.

I've figured out all the edge cases, though. There's not really much to it, syntax-wise. But implementing it won't be trivial. We have to do tag resolution, implicit and explicit, prewalk to detect duplicate refs on dumps, provide a nice API for custom tagging etc. Monkey-hacking this into existing implementations will be interesting.

Still, I think it is all very doable. I want to be sure to provide a nice and consistent API across all implementations. ie There needs to be an API spec, as well. I think that's one area where YAML has fallen down. I think if JSYNC is a success, then the API can be retrofitted to YAML implementations.

I'll address your points below...

* A tagged custom type which is constructed from (say) a string rather than from a map - my example was {"$tag": "!!timestamp",  "$value": "2001-12-15T02:59:43.1Z"}

"!!timestamp 2001-12-15T02:59:43.1Z"
 
* An anchor attached to a string/array/some non-map type - my example was {"$anchor": "foo", "$value": "some string"}

[ "&anchor1", "x", "y", "&anchor2 z"]

--- &anchor1
- x
- y
- &anchor2 z
 
* Use of one of the special reserved keys "!" or "&" as a normal key of a mapping (would need to be escaped somehow)

{
   ".!oh": "my!",
   ".&gt;": ">"
}

---
'!oh': my!
'&gt': '>'

* A map with non-string keys

{"!!int 4": "four"}

---
4: four
 
* A string value which starts with "*" which you don't want treated as a reference

[".*anchor"]

---
- '*anchor'
 
On that last point, perhaps it would be easier to do references as {"*": "001"} rather than "*001". That means that you then only need to reserve one other map key, "*", rather than have to reserve (and escape normal uses of) all strings starting with *, noting that this requires every string value to be checked when mapping a parsed JSON tree to a YAML graph.

I think that too complicated visually. You need to check every string node anyway, to see if it has a type or anchor, so no real penalty doing "*001".
 
> Want to help me with it?

Sure - see the above :)

Great. Join #jsync on irc.freenode.net if you do IRC.
 
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",
   "!!int 55": "I can't drive",
   "awesome": ".!!!"
}

--- !custom &anchor
55: I can't drive
awesome: '!!!'

Any thoughts on a media type for this? eg application/yaml+json ?

application/jsync ?
 
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.

Explain this more. I don't really see what you are proposing...

Cheers, Ingy
 
-Matt