remove of `subject.type`

[davidB]

Why should we remove subject.type?

subject.type seems useless, and to create more trouble (for SDK creator, user) that is solve:

• the content is defined by context.type, subject.type alone is not enough
• {{subject}} should be consistent between every places and consistent when associated with {{predicate}}, and converted into different format (snake_came, PascalCase, kebab-case, camelCase) when used in json, java, python,...
• extraction of {{subject}} and {{predicate}} from $id, context.type, filename (schema, examples) should be doable without ambiguity (=> no _,-, case variation into {{subject}})
• subject.type requires storing additional information into SDK (lookup table, mapping or static field) to be able to set it when generation json in sdk

Notes

from @afrittoli

Some of the subjects are made of two words, and that is rendered differently in different places because of different constraints or needs during the implementation. In the specification, we defined that subjects, when made of more than one world, should use camel case. Event types however must be all lowercase. ... This is a breaking change (backwards incompatible and one that I would prefer to do in steps:

• First step, mark subject.type as optional. It can be removed from the examples.
• Second step, ensure SDKs do not rely on this field to parse/produce events. Then mark the field as deprecated and planned for removal in the next minor release
• Third step - remove the field from the schemas. For the SDKs we'll have to decide how to manage this, since SDKs will have to be able to parse messages with the subject.type (when they have the correct version), and even produce them once we introduce support for producing messages of various versions

[afrittoli]

Thanks @davidB.

I've been thinking about this a bit more - one of the reasons for having a subject.type was that a certain subject could be re-used across events. However we opted instead to refer to other subjects via their source + id, so this reason is not valid anymore.

We already have content planned for v0.4, so I tentatively marked this for v0.5. I will bring this up during the working today, if folks are ok with it you could start working on it as soon as it's convenient for you.