Yeah, I don't know either. I see that the Wikipedia page for JSON describes it as a "data interchange format". Maybe that helps. I'd probably side-step the problem by having your home page start with "Like Protocol Buffers but more secure", followed immediately by the example you just gave me.
I guess I need to revamp what is emphasized and in what order. It's going to have to hammer on security all the way. Everything else is incidental and a "nice-to-have".
First, the need for tight and precise specs, not allowing optional or under-defined behaviors or too many features, and what goes wrong if a data format doesn't do that (I'll see if I can simplify the admin example or maybe do a $0 cost purchase exploit example).
Next, versioned documents and why that's important: Without it you're limited in how you can update the format to deal with emerging threats as they come along. Otherwise you get deprecations, loss of code space, and the possibility to get permanently stuck with an unfixable problem.
Then talk about fundamental type support and why we need so many: If you don't do that, everyone has to make their own encodings for common types (like dates, media etc), which won't be compatible or as carefully thought out, opening up security holes again.
The trick is how to make security sound sexy enough for people to take notice...