Introduce & standardize xdm:condition

[mhaack]

I think XDM should have a "conditional language" to have a standard way to define conditions when a property should be used or not. Conditions could refer to other attributes of the same or another XDM schema. The language should support basic checks like:

• is / is not present
• equals / not equals
• <, >
• contains (for arrays)

Examples of this are for example in the commerce area where products have prices which only apply to a certain region/customer group/channel/etc.

Example:

"xdm:condition": {
  "xdm:country": {
    "xdm:equals": "DE"
  },
  "xdm:channel.@type": {
    "xdm:equals": "https://ns.adobe.com/xdm/channel-types/web"
  }
}

[lrosenthol]

XDM is a declarative schema - it has no concepts of conditionals nor should it.

[trieloff]

@lrosenthol I disagree. XDM being declarative bears no relationship whatsoever to it having conditionals or not. For example, SQL and XSLT have support for conditional statements are are declarative languages.

Why does XDM need a common way of modeling conditions? Because the alternative is to model conditions not at all (reducing the usefulness of XDM in the applications below) or to model conditions in an inconsistent way.

Examples where conditions are needed:

• conditional pricing in commerce
• conditional discounts in commerce
• rule-based audience/segment membership for targeting
• rule-based branching for campaign or experience flows

[lrosenthol]

I don’t believe that we need conditionals in a declarative schema. Please elaborate on those specific uses cases and why they need such capabilities in the schema (vs. business rules outside the data definitions)

[trieloff]

Here are a couple of examples of existing applications that model conditions in JSON:

• JSON Schema, Draft 7 introduces if, then, and else keywords. The if condition itself is a JSON Schema http://json-schema.org/draft-07/json-schema-validation.html#rfc.section.6.6
• AWS IAM has a home-grown condition language that nicely illustrates the perils of ad-hoc modeling, with keywords as specific as DateGreaterThan https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html
• Zeebe (a workflow engine) specifies conditions in a "JavaScript-like" language and uses JSON Path to operate on JSON objects: https://docs.zeebe.io/reference/json-conditions.html
• JSONLogic models conditions as S-expressions http://jsonlogic.com

My personal preference order would be something like this:

1. JSON Schema: just use what we already have in the standard
2. JSONLogic: a simple language that is extensible and easy to implement
3. Zeebe: "just" run JavaScript – but ugly because we now have mixed two languages
4. the AWS Approach: just winging it

@mhaack could you verify that (1) works for you. Imagine you have a $data object that has properties for everything that would be available to the condition evaluation engine as properties and you write a schema that evaluates the condition.

[trieloff]

@lrosenthol let's take pricing as an example:

In the EU, stated prices must include VAT (value added tax) and the American practice of showing the price without tax and calculating what the customer will pay at checkout is illegal (false advertising). However, customers only have to pay VAT if they are residing in the EU, and are not a business.

So, an online shop would need to model two things:

1. different prices for EU and non-EU customers
2. personalized display of prices based on location inside or outside the Union

Because the online shop is typically a combination of multiple systems, these conditions need to be kept in sync between (at least)

1. the e-commerce backend (lest we charge the wrong amount)
2. the CMS/website frontend (lest we show the wrong amount and get sued for false advertising, or aren't being considered for the price being ~20% more than the nearest non-EU competitor)
3. the web analytics system (so that we don't mix up gross and net revenue in our analytics, attribution, etc. "wow, EU customers are so much more valuable than US customers – their average shopping cart has a 20% greater value")
4. the email marketing system (so that we can calculate the proper base price when offering a discount after cart abandonment)
5. the DMP (so that we can start re-targeting ads, but calculate the correct expected value of the conversion)

Modern experiences are personalized, and this means conditional. If we can't model the conditions, we can't model the experience.

Our products like AEM Commerce, but also Adobe Target, Audience Manager, etc. are using both conditions in their domain model and are using XDM as the schema for their APIs. If we keep business rules out of XDM, they will be kept out of the API, and will effectively either make the API useless, or make XDM partially irrelevant to our products (because they implement a private, non-standard business rule API)

[lrosenthol]

@trieloff I hadn't seen the if/then/else stuff in JSON Schema. Since that's the standard we are using - I agree with you, we should support it.

However, I still don't buy the argument about putting business rules inside of the XDMs.