Create expectations around sending "data" other than a JSON map

[kevmoo]

Many other JSON values: list, string, bool, etc
Text? What are the rules for decoding? Should the consumer get it as a language-specific "String"?
Binary data? I could imagine a conformance test when I just need to echo the length of the data or something - but it should be verified if it's supported

CC @grant

[kevmoo]

I see discussions in the spec draft around data_base64 – so maybe I'm jumping the gun a bit here

[grant]

Our CloudEvents don't really send anything crazy other than JSON which you can parse normally.

There are discussions around data_base64, but we don't use it for what I know. Not saying that isn't shouldn't be supported if we want.

There are examples of JSON and events in the conformance tests and https://github.com/googleapis/google-cloudevents repo.

[kevmoo]

@grant If the only thing that's really supported now is JSON Map it'd be GREAT if that was explicit in the spec (and conformance tests) now.

At the moment I'm (likely) going to hard-code the assumption and send a 400 if we get anything else – and just put this issue in a // TODO

[grant]

I'd assume a JSON object for all CloudEvent data fields. That's what I see for all event types from Eventarc.

[kevmoo]

I'm going to update the Dart impl to only support Map<String, dynamic> for data. Again, would be great if this were made explicit other places.

CC @grant