adobe / xdm

Experience Data Model
Creative Commons Attribution 4.0 International
245 stars 319 forks source link

Highlight schemas that emit events #68

Open trieloff opened 6 years ago

trieloff commented 6 years ago

Looking at #63, I think it makes sense to point out schemas that have associated events. One idea would be to have a meta:events property that is an array of URIs. Each URI points to an emittable event schema.

@theManikJindal WDYT?

theManikJindal commented 6 years ago

schemas that have associated events

I am unable to follow this statement.

Also, what kind of events are we talking about. I can understand C~R~UD & move events for resources, is there a 5th event type you have in mind?

Lastly, I am wondering, if there would exist a unified way of subscribing to those events as well?

@trieloff could you add some examples of this, maybe that will make it easier to grasp.

trieloff commented 6 years ago

Right now, we have following events in the repository:

The events don't give clear indication what the resources are that they apply to, and for a given resource, it is not possible to find out what events can be expected.

What I would do is to create a list of events for every schema, e.g.

Page

Asset

Directory

and so on.

theManikJindal commented 6 years ago

Hmm, I think I now follow what you are saying. My 2¢ -

The events don't give clear indication what the resources are that they apply to, and for a given resource, it is not possible to find out what events can be expected.

The entire point of Noun Verb separation was that the nouns and verbs can be mixed and matched as and when use cases arise.

Coming to the point of, documenting what all combinations exist - I am not at all opposed to doing that, however, I am failing to see how an end user would use that information.

It is not as if a single system is implementing all the combinations. Various systems can use schemas for the different resources present in XDM and emit events about those resources. Take for example - the rejected event which has been crossed out on your list for assets. However, nothing prevents an activity such as, asset rejected in the editorial line of work.

Could a better place for documenting these combinations be alongside API documentation, API that allows subscribing to events (noun-verb pair). WDYT?

trieloff commented 6 years ago

Aside:

Take for example - the rejected event which has been crossed out on your list for assets. However, nothing prevents an activity such as, asset rejected in the editorial line of work.

I'd have included rejected for asset and content if we had a corresponding approved event.

trieloff commented 6 years ago

I'd imagine an event system that follows XDM to link to the XDM docs saying: here are the events that I know and over there are the payloads and entities you can expect.

theManikJindal commented 6 years ago

I'd imagine an event system that follows XDM to link to the XDM docs saying: here are the events that I know and over there are the payloads and entities you can expect.

I agree.

how an end user would use that information.

Just this question remains.

trieloff commented 6 years ago

how an end user would use that information. Just this question remains.

Imagine a situation like this: a developer wants to build an application that consumes Adobe assets. Searches in Google for "Adobe Asset API", finds this page: https://github.com/adobe/xdm/blob/master/docs/reference/assets/asset.schema.md sees that there is an "updated" event available for assets and decides not to poll assets for changes, but instead to investigate how to consume this updated event.

theManikJindal commented 6 years ago

Let's do it! :)

rperelma commented 6 years ago

@theManikJindal what exactly are you committing to here? :)

theManikJindal commented 6 years ago

@rperelma not much, probably just a PR review. :)

trieloff commented 6 years ago

@kstreeter this could be a candidate for our schema descriptors: #154

cdegroot-adobe commented 6 years ago

I think this is quite Asset specific. The types of events that can happen on apps(web or mobile) are hard to fully quantify. I do like the idea of keeping this outside the schemas themselves.

trieloff commented 6 years ago

It's not asset specific. Almost any entity should be observable. Stuff that happens in visitor interaction is covered by ExperienceEvent, which is outside of the event-based API support.