Create an **implementations** section in the FDC3 website

[kriswest]

Enhancement Request

Additions need to be made to the FDC3 site to provide links to implementations (including Desktop agents, development apps and apps using the FDC3 desktop agent API) and to 'community context types' (contexts and intents used by apps that are not yet part of the standard).

Add an implementations page to the FDC3 website with the following goals:

• To highlight uptake of the FDC3 standard in applications and platforms and aid dissemination of relevant implementation details.
• To provide links to development tools and examples to aid developers getting started in FDC3
• To provide details on custom context and intent types used by applications implementing the standard, with a view to gathering information on those types for future standardisation efforts.

Content Recommendations

Update 'Who is using' copy to:

The Financial Desktop Connectivity and Collaboration Consortium (FDC3) standards are created and used by leading organizations across the financial industry. For more detail on who's using FDC3, developer tools and custom context and intent types, see the implementations page.

Implementations pages

Use same basic layouts as Docs pages:

Left Nav (sub pages navigation)

Implementations ⌄

• Platform Providers
• Application Providers
• Examples and Training
• Custom Types and Intents

Right Nav (in page navigation)

Link to each entry in the page. E.g.

Platform providers would have links for:

• Introduction
• Finsemble
• Glue42
• IHS Markit (or anyone else with a proprietary or white-labelled implementation)
• OpenFin

Application Providers

• Introduction
• ChartIQ
• Factset
• Reactive Trader
• etc.

Examples and Training

• Introduction
• FDC3 eXplained
• FDC3 Workbench

Custom Types and Intents

• Introduction
• Context: myapp.customInstrumentType
• Context: myapp.customOrderType
• Intent: myapp.ViewOrders

Page Content

Platform Providers

Introduction

A platform provider (also known as a Desktop Agent) supplies an implementation of the FDC3 (Desktop Agent) API for applications to use. A platform provider should also connect to one or more App Directories, which provide information about application's, including their identifiers, intents that provide contexts, and metadata specific to the launching and integration of the application.

Please see FDC Compliance for further information on meeting the requirements of FDC3 as a platform provider.

Details on Platforms that provide support for FDC3 are given below.

Add your platform

To add your platform to this page please raise a PR on the FDC3 Github repository.

<Platform name>

Website | Documentation
Overview/introduction copy about the platform provider. Should be limited to 100 words. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi vehicula sodales sapien porttitor porta. Orci varius natoque penatibus et magnis is parturient montes, nascetur ridiculus mus. Nulla in aliquam lectus. Praesent nec dolor nec lacus varius congue vitae at orci. Ut porttitor felis sit amet lectus pulvinar iaculis. Nunc efficitur ex nec dignissim aliquet. Integer pellentesque fermentum diam, id semper velit. Fusce vel faucibus arcu. Maecenas ut pretium massa, nec posuere est. Maecenas dapibus viverra orci vitae ullamcorper. Aliquam sed sagittis diam. Praesent gravida velit.

---

<next platform name>

...

Application Providers

Introduction

An application provider is a downstream consumer of FDC3 standards. In order to use FDC3, an application must be run in the context of an FDC3 platform provider (aka a desktop agent) which provides an implementation of the FDC3 API for it to use. Applications will usually be listed in an App Directory, which will provide information and metadata about the application to the desktop agent, including details on how to launch the application, its supported intents and other metadata such as version information and icon URLs.

Please see FDC Compliance for further information on meeting the requirements of FDC3 as an Application provider.

Details on applications that include support for FDC3 are given below:

Add your application

To add your application to this page please raise a PR on the FDC3 Github repository.

<application name>

Website | Documentation
Overview/introduction copy about the application. Should be limited to 100 words. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi vehicula sodales sapien porttitor porta. Orci varius natoque penatibus et magnis d#heading=h.bli547fq4v47is parturient montes, nascetur ridiculus mus. Nulla in aliquam lectus. Praesent nec dolor nec lacus varius congue vitae at orci. Ut porttitor felis sit amet lectus pulvinar iaculis. Nunc efficitur ex nec dignissim aliquet. Integer pellentesque fermentum diam, id semper velit. Fusce vel faucibus arcu. Maecenas ut pretium massa, nec posuere est. Maecenas dapibus viverra orci vitae ullamcorper. Aliquam sed sagittis diam. Praesent gravida velit.

Interop details

The following sections are examples of optional details you may provide to help others interoperate with your application

Custom context types

• myapp.customInstrumentType
• myapp.customOrderType

Context listening

• Listens to fdc3.organization and will filter orders displayed to those corresponding to that organisation

Context broadcast

• Broadcasts myapp.customInstrumentType and myapp.customOrderType whenever an order is selected in the main blotter and fdc3.organisation when an order filter is manually set..

App channels

• Broadcasts myapp.customOrderType on myapp-order-updates whenever new orders are received or existing orders change status.

Intents

• ViewChart: raised when a ticker symbol is double clicked on in the main blotter
• ViewOrder: listened for with context types myapp.customOrderType and fdc3.order

---

<next application name>

Website | Documentation
Overview/introduction copy about the application. Should be limited to 100 words. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi vehicula sodales sapien porttitor porta. Orci varius natoque penatibus et magnis d#heading=h.bli547fq4v47is parturient montes, nascetur ridiculus mus. Nulla in aliquam lectus. Praesent nec dolor nec lacus varius congue vitae at orci. Ut porttitor felis sit amet lectus pulvinar iaculis. Nunc efficitur ex nec dignissim aliquet. Integer pellentesque fermentum diam, id semper velit. Fusce vel faucibus arcu. Maecenas ut pretium massa, nec posuere est. Maecenas dapibus viverra orci vitae ullamcorper. Aliquam sed sagittis diam. Praesent gravida velit.

Interop details

Please see the Interop section of our documentation for details.

Examples and Training

Introduction

Developer tools, reference implementations, test applications and training materials that you can use when implementing FDC3 support in your platform or application, or when learning FDC3 for the first time, are listed below:

FDC3 eXplained

Website | Github repository
Overview/introduction copy about the tool. Should be limited to 100 words. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Morbi vehicula sodales sapien porttitor porta. Orci varius natoque penatibus et magnis is parturient montes, nascetur ridiculus mus. Nulla in aliquam lectus. Praesent nec dolor nec lacus varius congue vitae at orci. Ut porttitor felis sit amet lectus pulvinar iaculis. Nunc efficitur ex nec dignissim aliquet. Integer pellentesque fermentum diam, id semper velit. Fusce vel faucibus arcu. Maecenas ut pretium massa, nec posuere est. Maecenas dapibus viverra orci vitae ullamcorper. Aliquam sed sagittis diam. Praesent gravida velit.

---

<next tool>

Custom Types and Intents

Introduction

Most operations in the FDC3 API relate to sending or receiving context data objects, which encode the data being passed between applications. Where the FDC3 spec doesn't yet include sufficient intents or types to fulfill an application's use-case, firms must create custom intents or types to do so. To enable interoperability with other application providers, without prior coordination, firms may add details of their custom types here. This information can also be used to help guide future extension of the standard with new types & intents.

Context: myapp.customInstrumentType

Description of context type and usage, limited to at most 100 words. Praesent nec dolor nec lacus varius congue vitae at orci. Ut porttitor felis sit amet lectus pulvinar iaculis. Nunc efficitur ex nec dignissim aliquet. Integer pellentesque fermentum diam, id semper velit. Fusce vel faucibus arcu.

Used by

• Myapp (http://myapp.com)
• Some other app (info@someotherapp.com)

Details

Property	Type	Required	Example Value
type	string	Yes	'fdc3.instrument'
name	string	No	'Microsoft'
id.ticker	string	No	'MSFT'
id.BBG	string	No	'MSFT:US'
id.CUSIP	string	No	'594918104'
id.FDS_ID	string	No	'P8R3C2-R'

Example

const instrument = {
    type: 'fdc3.instrument',
    name: 'Microsoft',
    id: {
        ticker: 'MSFT',
        RIC: 'MSFT.OQ',
        ISIN: 'US5949181045'
    }
}

Context: myapp.customOrderType

...

Intent: myapp.ViewOrders

Description of intent and expected behavior, limited to at most 100 words. Praesent nec dolor nec lacus varius congue vitae at orci. Ut porttitor felis sit amet lectus pulvinar iaculis. Nunc efficitur ex nec dignissim aliquet. Integer pellentesque fermentum diam, id semper velit. Fusce vel faucibus arcu.

Used by

• Myapp (http://myapp.com)
• Some other app (info@someotherapp.com)

Intent Name

myapp.ViewOrders

Display Name

View Orders

Possible Contexts

• fdc3.organization
• myapp.customInstrumentType

[kriswest]

Consensus reached at #481 that this issue should move ahead and be implemented. More time will be allowed to review content proposal. Offer of implementation support from @lspiro-Tick42 and @kriswest

[robmoffat]

@kriswest @mindthegab re: badging.

I guess the apps list we can eventually source from the FINOS app directory.. is that the plan?

In the meantime, and talking to Gab's point about compliance testing, it would be nice if we could label the items (especially the agents) in the list with things like 2.0 compliant, untested, in progress, 1.2 compliant ?

thoughts?

[kriswest]

@robmoffat there are 3 categories to list:

• Platform providers (aka Desktop Agents), these consume AppD's but are not listed in them
• Apps: these might appear in the FINOS AppD, but also might not. I think it valid for us to list some that don't as they might be in other AppDs (e.g. maintained by vendor) or not publically available at all (say in-house apps that its still worth providing detail on, say for others to know about that might be interoperating with it)
• Example (apps, e.g. FDC3 workbench) and training materials (e.g. the LFX training course)

Hence, a FINOS hosted AppD might provide input into the apps category, but might not cover it all. It also won't cover all of the examples category. It will provide no info on the Platform providers category.

I'm all for listing compliance results, when we can produce them (i.e. when the conformance testing framework is ready) - however this will only cover platform providers. Nothing is as yet underway for app compliance testing (which I think is going to be much harder to achieve and might require manual testing).

When I have a minute I'll look at how we can add compliance info to the design. In the event that a platform is NOT compliant then I don't think we would list it at all (as by definition, its not n FDC3 desktop agent!).

For now I'll separate out the implementations page into its own PR. I needed to work it out at the same time as the spec re-org, but now that's nearly complete it can be separated to merge when we've got sufficient data for it.

[kriswest]

• Formal spec PR will no longer enable the implementations page (but keeps it and its data file in the project so we can get it populated): [WIP] 491 formal spec reorg #679
• New PR raised that will enable the page when we are ready to do so: 466 enable implementations page #698