Extensible JSON

30th Nov 2008

JSON has a number of advantages over XML, the main one being that it maps nicely onto the data structures developers are used to. However, it struggles a little with something that you could argue is an advantage of XML: decentralized extensibility. Creating ad-hoc extensions simply by adding new keys to someone else's schema works fine as long as everyone's playing together, but can we define a mechanism that is similar in capability to XML, where anyone can invent extensions without inadvertently colliding with someone else?

I've previously proposed the following, and I'm sure I'm not the only one:

The first thing I did here was invent a de-facto key name under which extensions can live. Ideally no JSON-based schema would ever define a key with the name $ext, knowing that it's used for extensions. The second thing is to separate each namespace out into its own object, so the namespace URIs don't get repeated over and over and so that, in theory, that innermost object could be an instance of another schema which you can pass into some other library that understands that schema without it needing to know that it's being used as an extension rather than a top-level object.

If the "magic key" $ext doesn't sit right, this could also be defined on a per-schema basis. A particular schema could say "Extension fields are allowed under the key extensions" and still use the above structure within the extensions field. Some schemas might use a different key name, or might forbid extensions altogether.

I'm sure I'm not the first person to propose a structure like this, and I know there is a certain amount of resistance to trying to formalize JSON schemas in the same way as XML schemas are usually defined, but I think moving forward we do need to find a way to re-use schemas across multiple applications rather than everyone rolling their own.

Comments

Extensible JSON

JSON has a number of advantages over XML, the main one being that it maps nicely onto the data structures developers are used to. However, it struggles a little with something that you could argue is an advantage of XML: decentralized extensibility. Creating ad-hoc extensions simply by adding new keys to someone else's schema works fine as long as everyone's playing together, but can we define a mechanism that is similar in capability to XML, where anyone can invent extensions without inadvertently colliding with someone else?

I've previously proposed the following, and I'm sure I'm not the only one:

The first thing I did here was invent a de-facto key name under which extensions can live. Ideally no JSON-based schema would ever define a key with the name $ext, knowing that it's used for extensions. The second thing is to separate each namespace out into its own object, so the namespace URIs don't get repeated over and over and so that, in theory, that innermost object could be an instance of another schema which you can pass into some other library that understands that schema without it needing to know that it's being used as an extension rather than a top-level object.

If the "magic key" $ext doesn't sit right, this could also be defined on a per-schema basis. A particular schema could say "Extension fields are allowed under the key extensions" and still use the above structure within the extensions field. Some schemas might use a different key name, or might forbid extensions altogether.

I'm sure I'm not the first person to propose a structure like this, and I know there is a certain amount of resistance to trying to formalize JSON schemas in the same way as XML schemas are usually defined, but I think moving forward we do need to find a way to re-use schemas across multiple applications rather than everyone rolling their own.