It looks that each event type has separate component defined:

[maheshc01]

          It looks that each event type has separate component defined:

          org.camaraproject.connectivity-insights-subscriptions.v0.network-quality-met:
            "#/components/schemas/EventNetworkQualityMet"
           org.camaraproject.connectivity-insights-subscriptions.v0.network-quality-not-met:
            "#/components/schemas/EventNetworkQualityNotMet"

Following suggestions for lines 891-898

Originally posted by @rartych in #67 (comment)

[maheshc01]

limiting to 2 events, EventNetworkQuality and EventSubscriptionEnds.
Both network-quality-met and network-quality-met is being handled in network-quality.

[maheshc01]

issue fixed in commit 630372b

[rartych]

@maheshc01 I followed the approach used in:
https://github.com/camaraproject/DeviceLocation/blob/main/code/API_definitions/geofencing-subscriptions.yaml
https://github.com/camaraproject/DeviceStatus/blob/main/code/API_definitions/device-reachability-status-subscriptions.yaml

[maheshc01]

Hi @rartych ,

I reviewed the approach taken by geofencing and device reachability. both of them have specific components defined for each event type which is understandable. I would still do it differently for device reachability and i will put a issue there for enhancement.

In case of connectivity insights the only event is network quality insights(other than subscription ends) and in the same components a number of threshold could either be marked as met vs not met (defined as enum). we cannot have 2 events as met vs not-met as in most cases all the define KPIs thresholds will not be mapped to same enum. In most cases will always have a combination of thresholds which are met and some of them which are not met.

Hope this makes sense.
Let me know if you need any further clarifications.

[rartych]

I used 2 event types as they were already defined in the proposed yaml file. So I have modified the naming to follow the template Design Guidelines and used them in the discriminator.
I am fine with 1 event type (beside subscription ends or other management related) - BTW: QoD uses only "org.camaraproject.quality-on-demand.v0.qos-status-changed".

[maheshc01]

thank you for the feedback and confirmation that 1 event type is good.
I will marked this issue as closed.

[maheshc01]

i see that the code changes are yet to be merged for this change. Will keep this issue open till the PR is reviewed and merged.