[RaphaelFakhri]

Fixes #1407

The JSON format states that the presence of the data and data_base64 members is mutually exclusive. The JSON schema in cloudevents/formats/cloudevents.json does not enforce this, so a validator accepts an event that has both members.

Proposed Changes

• Add a not/required constraint to cloudevents.json so that an event with both data and data_base64 fails validation. Events with only one of them, or neither, still validate.

Release Note

The JSON schema now rejects events that contain both `data` and `data_base64`.

[duglin]

Please remove this file - we don't need this kind of test. You can then also remove the changes to requirements.txt

[RaphaelFakhri]

Done in 4087a01. The test file and the requirements.txt change are removed.

[duglin]

One thing we should discuss is whether we want to support one of them being 'null' while the other isn't? To me "null" is the same as absent so I think perhaps this might be more appropriate:

   "not": {
     "description": "data and data_base64 must not both be non-null.",
     "required": ["data", "data_base64"],
     "properties": {
       "data":        { "not": { "type": "null" } },
       "data_base64": { "not": { "type": "null" } }
     }
   } 

@clemensv @jskeet any thoughts?

[jskeet]

I see the point about "null being absent" - but it's a more active way of expressing that there's no value, which makes me nervous about having both fields present even when one is null. I think it would be okay in terms of the strict interpretation of the spec, but I think it would be confusing to see. (When you see "data": null you think, "Ah, I now know there's no data" - when you then see "data_base64" with a value, it confounds that expectation.)

So basically I have a weakly held opinion that it's fine to prevent them both being present, even if one/both of them are null.

[duglin]

ok I can live w/o the null stuff - it's a bit of an edge case anyway.
But @RaphaelFakhri can you address the other comment?

[duglin]

thanks.
Approved on the 11/5 call