Should we split context & intent out of the main FDC3 standard?

[mistryvinay]

Question Area

[ ] App Directory
[ ] API
[x] Context Data
[x] Intents
[ ] Use Cases
[ ] Other

Question

Should we split context & intent out of the main FDC3 standard? This would remove the reliance on a release schedule which is aligned with the main API's. Improving the frequency of when new context and intents could be made available.

• Where would the context and intents live
• How they should be versioned

[mistryvinay]

Also consider releasing NPM module as a 'next' version with the newly generated types.

Originally posted by @kriswest in #749 (comment)

[robmoffat]

I think there's a lot of advantage to this. Personally, I would like to see more of a "repository"-style approach to CD&I, as I think having just "standard" and "proprietary" doesn't quite cut it. I would like to see:

• private context types, maybe used within a single app or a single vendor's apps.
• published context types, which can be used to interop with a given vendor's data structures, e.g. "symphony.chat" or "chartiq.chart"
• standardized context types, which are within the "fdc3.*" namespace like "fdc3.contact"

This would allow people to get on with sharing context and interop'ing without having to necessarily wait for standards to happen.

Versioning

Ideally, if we published these context types into a repository, we could version them all independently. For example, symphony might have multiple versions of 'symphony.chat'. We could use the existing type field on the context data for this 'symphony.chat@v1', say or add a version parameter.

[robmoffat]

Problems With Versioning

Let's say we have three versions of a type:

• 1.0, which has fields [a,b]
• 1.1, which has field [a] (a subtractive change)
• 1.2, which has fields [a, b, c] (an additive change)

Who would be able to send to who?

1.0 [a, b]	1.1 [a]	1.2 [a, b, c]	receiver version
✅		✅	1.0 [a, b]
✅	✅	✅	1.1 [a]
		✅	1.2 [a, b, c]

This is a problem because it means you can't upgrade a type easily.

• If an app A upgraded to using version 1.1, then all the apps on 1.0 listening to app A would fail, since they wouldn't receive the b field.
• If an app B upgraded to using version 1.2 then it wouldn't receive anything from app A or the others, since they wouldn't be sending the c field.

I think this essentially means we can't version context types in a semver-style way at all. All context types must have a unique version or be called something completely separate. (This is answering the question I raised above).

WDYT?

[robmoffat]

Where To Publish Types

Let's say we go with the idea in my earlier comment and allow anyone to publish types:

• private context types, maybe used within a single app or a single vendor's apps.
• published context types, which can be used to interop with a given vendor's data structures, e.g. "symphony.chat" or "chartiq.chart"
• standardized context types, which are within the "fdc3.*" namespace like "fdc3.contact"

For this to work, we need some kind of namespace.

We could use a java-style namespace technique. So, for example a Finsemble-published type might be com.finsemble.fdc3.thing, since Finsemble own the finsemble.com domain name.

This is the simplest suggestion. We might want to elaborate on that:

• What should we do about Schema discovery? Do we even care about that? e.g if I have a type com.finsemble.fdc3.thing can I look up a schema from:

  • https://context.fdc3.finos.org/com/finsemble/fdc3/thing.schema.json
  • https://json.schemastore.org/com.finsemble.fdc3.thing.json
  • https://fdc3.finsemble.com/fdc3-schemas/thing.schema.json
  • ... something else?

• How about registering types and providing documentation for them (perhaps even bindings?)

[robmoffat]

Discussion from the last CD&I, and current maintainer's meeting:

• Ignore (for now) difficulties around namespacing / versioning
• Allow people to publish a non-standard schema containing documentation via a PR.
• Allow these to be listed on the website somewhere so that people can browse and use what they want.

questions around : npm module, support in typescript, where this should live