Charles d'Avernas

> this uri endpoint can aggregate all your function defs and stick in the functions array which then is also validatable against our single functions schema @tsurdilo IMHO, your suggestion...

> this is a compile time resolve so yes you can validate its response json, otherwise implement the validation on service side that returns the resolved json, thats fine too...

> we are starting to look like google cloud workflow here On that specific subject, that's not necessarily a bad thing! Even though I'm sure we can perfectly work without...

@ricardozanini We do, but the [produceEventRef](https://github.com/serverlessworkflow/specification/blob/main/specification.md#Event-Definition) property is required: no way to just consume an event. I don't see why I should have to produce a bogus event just to...

I would as well propose to remove the non-ubiquitous, obsolete `invoke` property on the `eventRef`. There is no sync/async paradigm here, it's an abuse of language applied to a non-applicable...

> Think the reason for this is the event definition "source" property. If its consumed event then this has to be set to match the source where to consume from....

> i am not sure in how much % of cases you would consume and produce the exact same event definition, can you show example? Well, it's not a personal...

> source is required attribute by CE https://github.com/cloudevents/spec/blob/main/cloudevents/spec.md#required-attributes @tsurdilo Yes, but we are speaking of consuming (not producing) events: it's not because the spec mandates that CE must have a...

@tsurdilo yeah maybe, it's not the point of my feature request anyways. I just think that there is no added value to know that an event is gonna be consumed...

One is an action, which is chainable, the other is a whole state. I remember that @tsurdilo mentioned, when we had this discussion months ago, that doing what I propose...