Better Organization for schemas and example JSON payloads

[grant]

Expected Behavior

• It would be nice if this repo supported other representations for CloudEvent data like json/jsonschema/avro/etc.
• It would be nice if the folder name protos was more accurate.

I think it would make sense to change the protos directory to something more generic like schemas (my vote). Or removing that directory making google a top-level folder in this repo (google/ would make sense in google-cloudevents).

Actual Behavior

• The protos folder has other useful metadata like JSON samples, curl, JSON Schema. It's really nice having these files together.
• The testdata folder has the same structure, but is far from the source of truth (not in the same folder).

Example: https://github.com/googleapis/google-cloudevents/tree/master/proto/google/events/cloud/pubsub/v1

---

The downside of changing the folder would be any URLs to this schema as of now and some changes needed in the generators. But I think it would be worth it.

---

What are your thoughts @jskeet, @michaelawyu @grayside?

[jskeet]

Personally I'd prefer to go in the opposite direction. I'd rather have three top level directories:

• protos
• jsonschema
• testdata

(I'm still not personally convinced by having lots of curl scripts - I'd rather have a single README that shows how to make a curl request using one of the data files as the source of request information.)

To me, looking at a directory with multiple types of file - particularly when both JSON schema and the test data as .json files - feels messy. (As a parallel example, it's like having source code from multiple languages in a single directory.) Note that while all the files are together, they have to share a single directory structure, which is basically dictated by protos. With separate top-level directories, each kind of file can use whatever directory structure makes the most sense.

[grant]

Yeah, I think that approach is better.

We just need to make sure that the folder paths match exactly between those 3 representations and that it's easily discoverable.

That approach would also not break the API (CE-TYPE), which is crucial. Will create a PR.