Brief introductions from attendees including interest in context data and what they are looking to get out of the working group:

Tim Kolecke - At Citadel for nearly 20 years and has seen an evolving tech stack including current effort moving some systems to HTML5. Context data can make it easier to develop single pages that can talk to each other with loose coupling that looks tightly integrated. Tim has been on the FDC3 PMC since its inception.

Adam Lancaster - Works with Leslie Spiro on the product side of Glue42 with a focus on desktop interop. Tick42 is involved in a number of FDC3 working groups.

Johan Sandersson - Platform product manager at FactSet with platform being the glue between the many applications they have. Mainly responsible for Symphony integration and also Financial Objects standardization, which has relevance for FDC3 context objects. Also on the FDC3 Use cases WG. Looking to improve interop with all apps (e.g. Symphony, proprietary systems) and ideally reduce the conversation required around format, symbology classification, etc. Expects that FDC3 standards can make this smoother.

Vinod Mehta - Engineer at FactSet for 10 years. Projects include creating component versions of workstation elements able to be sold individually (including within OpenFin). Noted that some clients have already started looking for support for FDC3.

Tosha Ellison - Recently joined FINOS as Director of Member Success supporting members in a variety of ways and working closely with Rob Underwood on Programs and Aaron Williamson on Open Source Readiness. Background in financial services and technology. 

Communication will take place through a combination of

• Google Groups/mailing lists (joining, contributing to conversations, distribution)
• GitHub (e.g. hold context data specification)
• Confluence (meeting notes)

Updates to the specification will be through the FDC3 Context Data GitHub repo and Tim urged people to comment and provide feedback via any of the above.

Johan stated that they have clients interested in sending data as context data but that the clients haven't fully grasped the idea that this should be standard (e.g. taking the general idea but changing names rather than adhering to a specific naming convention).

This prompted discussion on the need for a published standard that is easy enough to use and for other platforms to consume. Some key points from the discussion:

• There are other similar definitions with similar aims for context data, e.g. JSON LD (https://json-ld.org/) but we are platform agnostic and focused on financial services.
• FDC3 Context Data is not a symbology solution and is not focused on modeling financial objects (which is done in the Financial Objects program). The focus is on providing a standard envelope and a standard set of identifiers that can be used to set a lowest common denominator for interop.
• Key aims for us are 
  • interoperate using commonly recognized context structures
  • require the minimal amount of info necessary to communicate
  • structure is set by the spec itself
  • make barriers to adoption as low as possible
• Top level is the envelope (including object definition and version)
• Second level is the pay load of the data (high level grouping of elements that are necessary to communicate the type of data being sent over the wire. Not just financial data types like security but also contacts, types of organizations, industry, etc.) All data should conform to the payload spec.
• In the example of a symbol, you may want to include as many identifiers as known, e.g. ticker, ISIN, CUSIP, BloombergID, RIC, etc. so the approach must be standard but flexible enough to be extended.
• The data should be human readable (you should be able to see what context is being communicated from one app to another).
• Some questions were raised around potential confusion from the Symphony example in the spec. Tim noted that the spec is designed to show FDC3 specific context objects as well as other types. For example, you might have different intents: "FDC3.Contact" and "Symphony.Contact" and the type will indicate this.
• Leslie agreed to send a note out regarding how this is used with intents.
• There was also discussion around having different/mixed contexts in a single payload and how you would communicate this. A context can have one or more items and each item can be described with one or more context types. It would be useful to have some additional examples in the spec or a separate page/markdown file showing uses and how this is linked to other projects. Leslie agreed to provide some examples.
• Other items to be clarified/completed:
  • Need an example of a Financial Objects object in FDC3 formats
  • Need clarification on the context data envelope and the standard for the data within that