CDM Context

[robmoffat]

Enhancement Request

Use Case:

Support CDM being passed between apps as context items.
I could list off hundreds of use cases here, many of which are already covered by FDC3. However, the ability to pass data app-to-app in a standard format is pretty useful.

Two examples:

• Sharing PriceQuantity information (see example)
• Sending details of lifecycle events (e.g. novation, cash flow etc).

Contexts

After discussion in #1603, it would be nice to have a fairly generic FDC3 container for some CDM data.

I'm thinking something like this:

{
            "type": "fdc3.cdm",   (1)
            "version": "6.0",         (2)
            "data": {  (3)
               "$schema": "https://cdm.finos.org/schemas/6.0/cdm-observable-asset-PriceQuantity.schema.json",     (4)
                "price": [
                    {
                        "value": {
                            "priceExpression": "PerUnitOfAmount",
                            "priceType": "Clean",
                            "price": [
                                {
                                    "value": 99.75
                                }
                            ],
                            "perUnitOfAmount": {
                                "currency": "USD"
                            }
                        }
                    }
                ],
                "quantity": [
                    {
                        "value": {
                            "schedule": [
                                {
                                    "value": 1000000
                                }
                            ],
                            "unitOfMeasure": "USD"
                        }
                    }
                ],
                "observable": {
                    "value": {
                        "productIdentifier": [
                            {
                                "identifier": "US1234567890",
                                "source": "CUSIP"
                            }
                        ]
                    }
                },
                "effectiveDate": {
                    "adjustableDate": {
                        "unadjustedDate": "2025-04-01",
                        "dateAdjustments": {
                            "businessDayConvention": "FOLLOWING",
                            "businessCenters": {
                                "businessCenter": [
                                    "USNY"
                                ]
                            }
                        }
                    }
                }
            }
        }

Some notes:

1. We discussed in the meeting that it might be best to just have an FDC3 object that can hold _any _ cdm. However, it would also be possible to use type for the different types of CDM object. I have a feeling that might be overkill for the amount of integration we need with FDC3.

2. CDM has its own versioning scheme. Since this moves independently of FDC3, we should probably include a version number in the json.

3. data... or can someone think of a better name for the container?

4. I think it would be also useful to include some kind of schema reference for the data you're adding. Is "$schema" allowed here? Or only at top level? 🤔

Related Broadcasting

The above example contains at least three "identifier"-style FDC3 contexts:

• A date
• A currency
• An instrument

Ideally, we should have some piece of FDC3 logic that is able to parse a CDM context and extract these items to be broadcast alongside the main fdc3.cdm context. This allows more intelligent updating of other context listeners.

[kriswest]

@robmoffat I think we probably do need to vary the type value for different CDM schemas, rather than just expressing that its a CDM model. Granted you could just listen for CDM contexts and then have a switch statement, but its not quite the FDC3 pattern WHere you can listen for more specific types) and it would be poor for intent resolution.

I did suggest (when we met on this) that a single schema could create multiple types (so the type field is an enum)... but on reflection that may not work at all well with our docs generator. We could have a general schema for CDM (with the data element referencing some high-level schema from CDM) and refine it for specific types? However, that end up more complex rather than less.

Utility functions for converting/extracting CDM types to populate FDC3 equivalents that can also be broadcast (as is the FDC3 convention documented here: https://fdc3.finos.org/docs/api/spec#broadcasting-and-listening-for-multiple-context-types) seems a good idea. Utility code ciuld live in methods.ts, a new CDM specific file or the toolbox.

[kriswest]

data... or can someone think of a better name for the container?

How about just cdm?

I think it would be also useful to include some kind of schema reference for the data you're adding. Is "$schema" allowed here? Or only at top level? 🤔

Your example is somewhat of a blend of json schema and the output json, but I get what you mean by it. Its not $schema that you want but $ref. Instead of providing a definition for data just give it a $ref:

"data": {
  "$ref": "https://cdm.finos.org/schemas/6.0/cdm-observable-asset-PriceQuantity.schema.json"
}

Type generation etc. will pull in the schema, but our docs generator will just show a reference. There's code in the docs generator for making refs to our own schemas into nice links - that can probably be extended to link out to docs for CDM schemas. Given the references, examples for each schema we think is relevant to a use case will be really important for our docs pages.

CDM has its own versioning scheme. Since this moves independently of FDC3, we should probably include a version number in the json.

I note the schema URL contains the version number so the reference is essentially encoding that accurately without us adding and additional field. However, I also note the example URL doesn't resolve to the schema and I can't immediately find it through the CDM docs site of GitHub repo... Do you know where they live? I suspect that the version number is also baked into a field in the schema so we'd inherit the version field anyway by referencing the schema.

[kriswest]

P.S. schemas not living at their $id URLs is inconvenient, but doesn't prevent and isn't required:

Common Pitfall
In JSON Schema, schema identifiers are merely identifiers and no behaviour is imposed on them. In particular, JSON Schema does not guarantee that a schema with an HTTP URL identifier is actually resolvable at such URL. To avoid surprises, JSON Schema implementations must be careful with automatically sending remote network requests when encountering supposely resolvable schema identifiers.

But it is Best practice:

Best Practice
It is strongly recommended for every schema file to explicitly declare an absolute URI using this keyword. By doing so, you completely avoid various complex URI resolution edge cases, mainly when the base URI is implicit and context-dependent.

If you are serving schemas over the network (i.e. over HTTP), it is common to set this keyword to the target URL.
...

https://www.learnjsonschema.com/2020-12/core/id/

If the schemas are not at the stated $id URLs, then you need to have local copies of the schemas to pass to whatever is resolving them (we will need them in order to run code and type generation). Whereas if they live at the $id URLs most tools will retrieve them themselves quite happily.

I had said:

There's code in the docs generator for making refs to our own schemas into nice links - that can probably be extended to link out to docs for CDM schemas.

We'd need to figure out where to link to for each schema. I was hoping we could figure out a docs link for each schema programmatically, or at least a link to the schema file... This may be a question for the CDM project.

[robmoffat]

This may be a question for the CDM project.

Yes. Hopefully something they are doing, although it's non-obvious how?

@minesh-s-patel @iansloyan are you guys publishing the CDM schemas?