> Also lack of inheritance support. (For example I want a way to specify that my json object should be deserialized as Dog not as Animal.)

Use Typescript, then so long as it barks, you can treat it like a dog!

And if it knows how to bark and meow, you can treat it as a dog or a cat at your leisure. :-D

The issue is when JSON has to be parsed on the server using Java/C#. How do you know whether to parse it as a Dog or as a Cat (both of which inherits from Animal)?

Here's Microsoft's workaround: https://devblogs.microsoft.com/dotnet/system-text-json-in-do...

I must admit I'm a noob in this world so maybe I'm going about it the wrong way, but I used JSON Schema's oneOf[1] along with required[2] for this:

    "properties": {
      "cat": {
        "$ref": "#/$defs/catType"
      }
      "dog": {
        "$ref": "#/$defs/dogType"
      }
    },
    "oneOf": [
      {
        "required": ["cat"]
      },
      {
        "required": ["dog"]
      },
    ]

Usage would then look like:

    {
      "dog": {
        "name": "Charlie"
      }
    }

At least it's explicit and can be easily checked for validity.

[1]: https://json-schema.org/understanding-json-schema/reference/...

[2]: https://json-schema.org/understanding-json-schema/reference/...

You are doing it correctly.

https://en.wikipedia.org/wiki/Tagged_union

> The issue is when JSON has to be parsed on the server using Java/C#. How do you know whether to parse it as a Dog or as a Cat (both of which inherits from Animal)?

I mean how MS does it, yeah, you have a tagged union, look at the tag to determine what it is.

Heck even networking packets work this way, UDP or TCP, look at the Protocol Field on the IP packet to see which it is.

I think JSON allows both of your use cases, you'll just have to define your own deserialization.

We've used { "__type": "DOG" } as metadata flags in GraphQL and JSON API's for a long time.

I rarely see an API return anything other than an ISO8601 UTC datetime string anymore other than Xero's horrific .NET(?) string " /Date(1326480130277+1300)/"

Lets invent JAYSON :D

   (dog){
      "ears": [(ear){"side": "right"}, (ear){"side": "left"}]
      {% this is a comment %}
   }

Now we only have to invent attributes, and we can sell this XML skin to the enterprise JSON users.

(This is only half sarcasm)

EDIT: Even Better, make comments a subtree by having a special type tag, like #. this way, (#,dog){...} can stay in the tree, but is ignored.

No, it's not the right place.

Correct, so let's maintain the tradition. After all we don't usually have precise enough topics, so we can deviate a little and use the opportunity.

Date type reminds about some network-specific types which used to be in older version of JSON Schema (like IPv4 address?). Today we can use a string with regexp for an approximation. Do we have a mechanism in JSON Schema to define, mmm, dialects?..

Deserialization of a number as an integer, not a double, could be a similar problem. We can agree that we (try to) deserialize to most abstract class (?) or to use external explicit indicators of the class.

JSON schema doesn't deal with how your language treats the underlying data - and shouldn't do it.

Use custom deserializers for that.

This doesn't deal with what type of object you create on deserialization, but you can have some form of inheritance in JSON Schema. You create a definition for the parent class and then reference that definition in the subclass and add whatever other attributes you need. JSON Schema doesn't have any understanding of classes, but this will allow you to do something similar.