adobe / adobe/xdm

Support OneOf for Subtyping where only object obeying one subschema is the correct structure

Open
#406 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
266
Forks
380
Avg merge
5d 8h
Merged PRs (30d)
9

Description

## What are the schemas that are affected by the issue
schemas/context/segmentmembership.schema.json
See for https://github.com/adobe/xdm/pull/411/files for specific example of what I'm trying to do.

## What are examples of products that are impacted by the issue
Audience Manager

## Issue
It's pretty common paradigm in OO languages to have a parent type for an object property and want to be able to accept a subtype, but not multiple subtypes. Trying to express this in XDM is difficult in a way that enforces the correct structure.

In my use case, I am trying to design a system where segment membership can have a value associated with the membership. This value can be either a string, a number, boolean, or future types depending on specific use cases. The type of this value is ultimately based on the segment definition (which I am not currently modeling). Still, in the membership, I want to at least explicitly enforce that the membership store only a single type of value.

This can't be modeled just as customer extensions to the segment membership schema since ultimately it's not that a customer would only use a single value type. Again, it's tied to the segment definitions that they have, which will easily number in the 10 to 100 thousands (and of different types). There are some common types we should capture.

My proposal is that we allow use of OneOf where:

- Any of the common properties in the subschemas specified are always of the same type
- Any properties that are not common are uniquely named

cc: @chrisdegroot @kstreeter @cmathis

Contributor guide

Open the contributing guide

Research direction

Start with schemas/context/segmentmembership.schema.json and compare the specific example in the linked adobe/xdm pull request. Review how the proposed OneOf behavior would enforce one subtype and identify the affected schema rules; done means the proposal is defined well enough to implement and validate against the stated segment-membership cases.

Written by the indexing model from the issue text.

Assessment

Domain
backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.