Add an optional header for repeating definitions and typed objects

[iJungleboy]

Maybe I'm overshooting a bit, but I'm researching typed JSON to standardize how CMSs can exchange information in a structured but light way. What I would like to propose is

1. An optional header in a JSON to provide various types of optimizations
2. A typed object definition capabilities
3. Default type for the following data - allowing the rest of the JSON to look untyped, while parsers have all the type information they need

Optional header

I don't have a clear idea yet, but what if a root node could be like this:

{
  "": {
    // header stuff
  },
  "name:s": "Daniel",
  "etc:x": "..."
}

The idea is that the header is very optional, but I believe it could have some very neat features.

Pre-Typed Objects

Since we could have things like "User:O" it would be even nicer to have a "User:Person", which is pre-typed, a bit like a schema. This would actually allow the following data to be simple keys, without additional type tags:

{ "": {
    "Person:{}": {
      "Name": "s",
      "Birthday": "t",
      "SocialSecurity": "/some/regex/"
    }
  },
  "User:Person": {
    "Name": "Daniel",
    "Birthday": "1999-09-09T01:02:03Z",
    "SocialSecurity": "abcd-efgh-ijklm"
  }
}

The extra benefit of this would be that if you have multiple objects in the same file which should adhere to a type, it's clearer how it should be enforced.

Pre-Typed Default

If the above is reasonable to implement, we could often even simplify the main data even more, if there is a definition for "default data". This would make processing the remaining data side-effect-free, in case it's processed by a non-type-aware system, a bit like this:

{
  "": {
    "Person:{default}": {
      "Name": "s",
      "Birthday": "t",
      "SocialSecurity": "/some/regex/"
    }
  },
  "User": {
    "Name": "Daniel",
    "Birthday": "1999-09-09T01:02:03Z",
    "SocialSecurity": "abcd-efgh-ijklm"
  }
}

Now the exact specs like empty-key=header, or {} is typed object etc. are not really thought through. I'm just suggesting this for discussion.

[tarcieri]

Take a look #41, which I think covers everything you proposed here. I closed that as there wasn't a whole lot of interest and it's also rather complicated, and wanted to keep the spec tight and focused. It also seems to me like at that point you should be using a schema. I'm willing to reconsider though.