Clarify @id for Identity

[fmeschbe]

Issue #419 (PR #420) propose to drop the URI formatted @id property in favor of a simple string id property.

There is a train of thought along the lines of All schemes SHALL have the @id property. But it MAY be optional (quoting @lrosenthol). I am sympathetic to this thought.

Essentially, the schema looks like

{
  "xdm:id": { "type": "string" },
  "xdm:namespace": { "$ref": "https://ns.adobe.com/xdm/context/namespace" },
  "xdm:xid": { "type": "string" },
  "xdm:primary": { "type": "boolean", "default": false }
}

(where xdm:namespace is a single mandatory property xdm:code of type string)

The issues are:

• None of the fields is mandatory, so technically an empty object is a "valid" Identity
• xdm:id requires xdm:namespace to be a proper identity
• xdm:xid by itself is unique and is a mapping for xdm:id plus xdm:namespace
• @id is not defined for this schema

So we have to fix the real optionality of the properties and we have to define how to look at the @id property.

First of all, having an @id property makes sense as a unique identity of something. But having this property optional does not really add value to such an important field as an identity.

Proposal for discussion:

For the @id property we could consider defining an URN namespace, say adobe-id which requires the xdm:id and xdm:namespace.xdm:code properties in a form like urn:adobe-id:<xdm:namespace.xdm:code>:<xdm:id>. For example urn:adobe-id:Email:[email protected]

(Such a definition, of course, would require the values for xdm:code and xdm:id to be restricted. See also #432)

Note: This issue summary represents the current state of knowledge and discussion. As we evolve the discussion around this issue, the scope of this issue may shift.

What are the schemas that are affected by the issue

Identity I in fact see a number of practical problems.

What are examples of products that are impacted by the issue

Analytics, Campaign, Ad Cloud, Target