Issue 517 - Unify representation of end-user identity between ExperienceEvent and Profile #523
Conversation
| { | ||
| "xdm:id": "2394509340-30453470347", | ||
| "xdm:namespace": { | ||
| "xdm:code": "AVID" |
There was a problem hiding this comment.
Is the code redundant? I take it this part is optional and all of xdm:namespace could be considered optional?
There was a problem hiding this comment.
If the intention of using an ID is to have a stable reference to the namespace and not have systems use the code in their implementations, then we should remove it. There's nothing stopping any implementation from assuming the code can be used for generating a fully qualified identity.
There was a problem hiding this comment.
This structure allows for specifying different namespace codes mapped to the same namespace key. Is that OK? If not, xdm:namespace should be outside the id object.
There was a problem hiding this comment.
Since the code can change, it makes sense to allow for the current value to (optionally) be captured in the data.
There was a problem hiding this comment.
If we want both id and code how we are planning to get id at the time of ETL. Are we saying ETL ecosystem with integrate with Adobe Service to fetch id?
There was a problem hiding this comment.
Also, if keys are going to be represented as "https://data.adobe.io/entities/namespace/4" how are we going to use this in json pointer notation. REF-> https://tools.ietf.org/html/rfc6901
There was a problem hiding this comment.
@rkpandey the mechanism is that external callers use the integration code (as it is the user-facing "handle" for the namespace), and the system transforms to id for storage as appropriate. The interface is the code, while the id is used internally.
There is no incompatibility between URIs and JSON Pointer. JSON Pointer allows for escaping of reserved characters.
There was a problem hiding this comment.
@harleensahni , @biswas-adobe see new definition that includes only the xdm:id and authenticated state in the map entry.
|
@kstreeter ProfileStitch Identities should also be updated: https://github.com/adobe/xdm/blob/master/schemas/context/profilestitch.schema.json#L26 to use IdentityMap for consistency. |
|
This breaks open source tools. Json key names need to compliant with open source tools. Using urls/uris in keys breaks these tools. |
|
@kstreeter - we also have another identities[] representation here https://github.com/adobe/xdm/blob/master/schemas/context/profilestitch.schema.json What do you wan to do with this? considering we are moving away for the identities array? |
| "xdm:code": "ECID" | ||
| } | ||
| } | ||
| "xdm:identityNap": { |
There was a problem hiding this comment.
Misspelling "identityNap"
| @@ -38,9 +38,15 @@ | |||
| "description": "The time at which this interaction was received by a server." | |||
| }, | |||
| "xdm:endUserIDs": { | |||
| "meta:status": "deprecated", | |||
There was a problem hiding this comment.
I thought the plan was to make this a breaking change and just remove it so we're clean.
There was a problem hiding this comment.
we are going to do an initial drop of this change with both to help testing. We will drop the older fields when we do the larger schema refactor.
temporarily relax required fields to aide in transition to identityMap
This PR addresses issue #517.
Currently, EE and Profile have different representations of end user identities. This has caused some confusion by implementors, and in addition the representation in EE cannot carry multiple identities of a single namespace, which is a problem for some use cases.
The new representation uses the newly introduced "map" type to model identities as a map from identity namespace ID to one or more instances of the
Identityschema. This makes it possible to carry multiple identities from a single namespace (which was possible with the array representation), while still doing direct lookups for the presence of identities of a specific space (which was not possible with the array representation).