oasis-tcs / cxs-cdp Goto Github PK

https://docs.oasis-open.org/cxs/cdp/v1.0/cs01/cdp-v1.0-cs01.html#_cdp_profileupdateeventfilter
https://docs.oasis-open.org/cxs/cdp/v1.0/cs01/cdp-v1.0-cs01.html#_cdp_profileupdateeventfilterinput

Can we acknowledge people that are no longer members but were previously ?
Can we get examples of conformance clauses ?

Make a PR on this document

https://github.com/graphql/graphql-spec/blob/master/rfcs/InputUnion.md

Should we add a server metadata field to indicate information such as :

• API version
• Supported level
• Server identifiers ?
• Other extensible fields that implementations might want to expose.

This could be done in a review of the specification if needed.

That was discussed with @sergehuber

Because this fields belongs to Profile and its ID is already available.

Try to eliminate the following:
Type "CDP_EventInterface" is missing a "__resolveType" resolver. Pass false into "resolverValidationOptions.requireResolversForResolveType" to disable this warning.
Type "CDP_ProfileInterface" is missing a "__resolveType" resolver. Pass false into "resolverValidationOptions.requireResolversForResolveType" to disable this warning.
Type "CDP_PropertyInterface" is missing a "__resolveType" resolver. Pass false into "resolverValidationOptions.requireResolversForResolveType" to disable this warning.

The CDP_ProfileFilter type was replaced by the JSON scalar. As the result there are types which do not use anymore:

type CDP_ProfileFilter {
  ...
  properties : CDP_ProfilePropertiesFilter
  interests : CDP_InterestFilter
  events : CDP_ProfileEventsFilter
}

and

type CDP_ProfileEventsFilter {
  eventFilter : CDP_EventFilter
}

and

type CDP_EventFilter {
  cdp_location_distance : CDP_GeoDistanceFilter
  cdp_profileUpdateEvent : CDP_ProfileUpdateEventFilter
  cdp_consentUpdateEvent : CDP_ConsentUpdateEventFilter
  cdp_listsUpdateEvent : CDP_ListsUpdateEventFilter
  cdp_sessionEvent : CDP_SessionEventFilter
  # generated event types will be listed here
}

Those types can be removed from spec.

CDP_SessionEventInput and Filters should be extended by unomi_sessionId and unomi_scope fields to be able to create a new session or find a specific session which should be start/stop and so on

Types AS IS:

input CDP_SessionEventInput {
  state : CDP_SessionState
}

type CDP_SessionEventFilter {
  state_equals : CDP_SessionState
}

input CDP_SessionEventFilterInput {
  state_equals : CDP_SessionState
}

Types AS SHOULD BE:

input CDP_SessionEventInput {
  state : CDP_SessionState
  unomi_sessionId: String!
  unomi_scope: String!
}

type CDP_SessionEventFilter {
  state_equals : CDP_SessionState
  unomi_sessionId_equals: String
  unomi_scope_equals: String
}

input CDP_SessionEventFilterInput {
  state_equals : CDP_SessionState
  unomi_sessionId_equals: String
  unomi_scope_equals: String
}

The idea is to check that we aren't missing any important types.

We received some internal feedback about the spec, let's discuss it in the next workshop.

Description of fields is missing in the specification https://docs.oasis-open.org/cxs/cdp/v1.0/cs01/cdp-v1.0-cs01.html for the following types:

• CDP_ProfileConnection
• CDP_EventConnection

Remove types CDP_InterestConnection and CDP_InterestEdge because they are not used

Currently property definition mutations are mandatory.

We could make them optional, so that implementations that have other ways of defining properties may still support the basic specification.

And it returns CDP_PropertyConnection so needs following arguments:

• first
• last
  Following are used by other connections, but may not be needed here:
• after
• before

We prefer that anyone can use this as a "boot starter" to offer a CDP API.

CDP_ProfileFilter is not properly structured. For example, when doing a getSegment it will return a structure but we have to know in advance which fields should be returned.

So instead we should define it as something like this:

CDP_ProfileFilter {
filter: JSON!
}

And the JSON should be structured exactly as the CDP_ProfileFilterInput is structured, making it easy to send it back for updating.

I was browsing the GraphQL schema with the GraphQL playground and was finding it to be a bit empty in terms of descriptions.

I was wondering if we should put links to the specification for each object type ? The difficulty would be how to make sure those links wouldn't change over time. They would need to use anchors and a stable base URL.

I'm not saying this is required but it would make understanding the specs from the schema a bit easier.