of what? Presumably a serialization of this JSON string without the signature field or something like that?

The introduction of this option means that a field must be added to the TLV format in front of oracle_signature specifying what the oracle has signed (TLV vs. JSON vs. other) as the client will have to reconstruct that message from the TLV.

To answer to both your questions, it's a good point that I hadn't specified this. My thinking was that it would be the same signature as the TLV version. It could be nice and practical to allow signature of JSON messages, but JSON being non canonical it's not trivial to do. We would need to adopt a specification for that or make a custom one which feels cumbersome.
Also (as you mention here) we would need clients to at the end probably support both signing format. I feel instead it is better to have oralce implement TLV signing which compared to the client TLV is not that hard to implement IMHO.

Note that JSON messages being non canonical does not make it difficult to sign them. It is of course very difficult if you are trying to embed the JSON that is signed along side the signature. The most straightforward way is to encode the json in a string inside the outer json.

curl -sL https://h00.ooo/time/2021-06-02T01:00:00?occur | jq
{
  "announcement": {
    "oracle_event": {
      "encoding": "json",
      "data": "{\"id\":\"/time/2021-06-02T01:00:00?occur\",\"expected_outcome_time\":\"2021-06-02T01:00:00\",\"descriptor\":{\"type\":\"enum\",\"outcomes\":[\"true\"]},\"nonces\":[\"0c2f40112642c09db886e5ce24ed94687ea022e0616990e1cfc0104348dc7a43\"]}"
    },
    "signature": "4c4861d830e9914351b59daacbb58b17d62865319163f732e399f2102e1080273729ecef419f7d04e536ca9e730e8d16793df56e8c3c716e7e28dba6c9a0df02"
  },
  "attestation": null
}

Then after verifying the signature you decode the announcement:

curl -sL https://h00.ooo/time/2021-06-02T01:00:00?occur | jq .announcement.oracle_event.data -r | jq
{
  "id": "/time/2021-06-02T01:00:00?occur",
  "expected_outcome_time": "2021-06-02T01:00:00",
  "descriptor": {
    "type": "enum",
    "outcomes": [
      "true"
    ]
  },
  "nonces": [
    "0c2f40112642c09db886e5ce24ed94687ea022e0616990e1cfc0104348dc7a43"
  ]
}

Yeah so that's one way. We would need to define how we encode the string as well. But what doesn't work very well is if we want to pass along announcements to counter parties. Of course we could embed the string again as well, but I feel it becomes complicated personally (and quite inefficient).