Context Data & Intents Discussion group - 2 Feb 2023

[mistryvinay]

Group overview

At the FDC3 Use Cases Roundtable London, October 5th 2021 participants agreed that the FDC3 lexicon needs to be expanded, both with additional intents and context types to support Use Cases, but also to include more primitive data types in order to construct complex types. A number of participants also agreed that now is an appropriate time to expand the Lexicon.
​
See #455 for full details of the meeting outcomes.
​
This group is being convened to discuss and arrange work to contribute further Context types and Intents to support Use Cases being implemented by participants.

Relevant issue tags

Current open issues that relate to the discussion group:

Issues will also be tagged with the labels:

Meeting Date

Thursday 2 Feb 2023 - 9am EST / 2pm GMT

WebEx info

• Meeting Link: https://finos.webex.com/finos/j.php?MTID=mbb193ae433ce8d4366adcecd94355734
• Meeting number: 2556 257 8293

More ways to join

• Join by video system:
  • Dial 25562578293@finos.webex.com
  • You can also dial 173.243.2.68 and enter your meeting number
• Join by phone
  • +1-415-655-0003 US Toll
  • +44-20319-88141 UK Toll
• Access code: 2556 257 8293

Meeting notices

• FINOS Project leads are responsible for observing the FINOS guidelines for running project meetings. Project maintainers can find additional resources in the FINOS Maintainers Cheatsheet.

• All participants in FINOS project meetings are subject to the LF Antitrust Policy, the FINOS Community Code of Conduct and all other FINOS policies.

• FINOS meetings involve participation by industry competitors, and it is the intention of FINOS and the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Please contact legal@finos.org with any questions.

• FINOS project meetings may be recorded for use solely by the FINOS team for administration purposes. In very limited instances, and with explicit approval, recordings may be made more widely available.

• A Discussion Group has no direct decision-making power regarding the FDC3 standard - rather it is intended that anything they propose or work on will result in proposals (via Github issues and PRs) for the Standards Working Group participants to consider and vote on for inclusion in the standard.

Agenda

• Convene & roll call, review meeting notices (5mins)
• Review action items from previous meeting (0mins)
• Discussion of open issues (30mins)
  • Clarify handling of malformed context objects by Desktop Agents #872
  • Question: Why do RecipientsID and RecipientsObject exist? #853
  • RecipientsObject interface has un unnecessary required type property #854
  • Tighter definition for "otherConfig" in fdc3.chart context type #856
  • Actionable Notifications via Intent & Context #828
• PR's ready to merged into 2.1 Milestone release (3mins)
  • 592 intent proposal create interaction #747
  • 592 771 context proposal TransactionResult #761
  • make chatInitSettings inherit from Context #869
  • fix/855 Fix incorrect format and rename 'public' property #875
  • Symphony PRs in FDC3 2.1 candidates #882
• AOB & Adjourn (5mins)

Minutes

• Clarify handling of malformed context objects by Desktop Agents #872
  • During implementation of the Conformance Tool (Conformance 1.2 Test Pack #848 ) it became apparent that malformed contexts are not handled correctly
    • If there is a type field missing, where one is required
    • Channels which listen for all context or type of context would not be able to listen or handle this message
    • Some desktop agents were also carrying the object over even thou it was malformed
    • Should the API be rejecting the message with an error
      • Avoid it being broadcast across channels
      • Desktop agent compliance, should they enforce the standard definitions for require and should
    • Are we doing enough within the Context and Intents standard? Or should we be including an error type?
    • @hampshan checked the type field, we can only do this for standardised types using Desktop Agent (DA).
      • The DA may not know about custom context and intents.
    • Enforcement of standard on DA, currently no one is doing that
  • Question: Why do RecipientsID and RecipientsObject exist? #853
    • Standard are defined in a JSON schema. Using a type generator these are then created into types
      • Do we manually maintain a typescript type?
      • Looking for other type generation systems
        • Type Script maybe difficult to fix - would require implementing and passing a custom generator to handle, this needs investigation however
  • RecipientsObject interface has un unnecessary required type property #854
    • Same as above issue. Will close this issue and link to related issue Question: Why do RecipientsID and RecipientsObject exist? #853
  • Tighter definition for "otherConfig" in fdc3.chart context type #856
    • Enhancement request to add more structure around otherConfig
    • Instead of object use an array as it has type fields. So you can be specific.
    • Schema change would be required for otherConfig to include an array for additional config
    • Next steps are to raise a PR for this change
      • Feedback on otherConfig. Should it be changed to an array? As its a breaking change.
      • Or put an array under otherConfig. Which is not a breaking change.
  • Actionable Notifications via Intent & Context #828
  • Interested in opinions from the teams on how you feel about this approach. Specific proposal for notifications.
  • Will be discussed at next Standards Working Group Meeting (SWG) 23rd Feb
  • 2.1 Milestone Release
    • No roadmap has been defined yet.
      • Timeline scoping will happen after February's SWG meeting.
      • March: Votes for additions to be included in the standard
      • April: Will need PR's in place by April's SWG meeting
      • June: 2.1 Standard ready to be announced
  • Context Proposal: Order #644
  • Refine and move forward with this PR and label as experimental
  • @timjenkel often we don't need much more than the orderId to make an API call to retrieve order details
    • @dominicgifford and @nemery-flextrade had also come to a similar conclusion which had stalled the modelling work
  • @kriswest suggested that perhaps we should draw back to super simple types for order/trade/position and focus on the use-cases first. The objects can always be better defined later
  • @dominicgifford to raise an issue to capture these ideas ahead of next meeting
    • Done: Question: What use cases and Intents related to Orders, Trades and Positions are there? #904

Action Items

• @kriswest convey opinion on malformed contexts(Clarify handling of malformed context objects by Desktop Agents #872 ) back to SWG. Type is enough, we should reply with an error
• @dominicgifford raise issue to track use-cases for order, trade and position
• @ALL Bring along ideas of intents that would be nice-to-have to embody trade, order and position types.

Untracked attendees

Full name	Affiliation	GitHub username

[kriswest]

Kris West / Finsemble 🚀

[mistryvinay]

Vinay Mistry / Symphony

[symphony-jean-michael]

Jean-Michael Legait / Symphony

[robmoffat]

Rob / FINOS

[timjenkel]

Tim / Wellington

[dominicgifford]

Dom / SPGI

[milindchidrawar]

Milind Chidrawar / Singletrack

[hampshan]

Andrew Hampshire @ UBS

[florian-gandon]

Florian Gandon / BTCS (Broadridge), ex-Itiviti

[pierreneu]

Pierre Neu @ Symphony