-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trade, Order, Product and RFQ context types #1503
base: fdc3-web-impl-update-docusaurus
Are you sure you want to change the base?
Trade, Order, Product and RFQ context types #1503
Conversation
✅ Deploy Preview for fdc3 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
@VedPrakashJha-FMR @nemery @dominicgifford Perhaps you could contribute your expertise to this. I can't help much with the field definitions (I've done my best to figure them out from Vinay's example) but I can facilitate on schema definition etc. Product is where we most need input, where need to be able model all possible product types: |
I'm not sure I am up-to-date with current discussions on this area but we've previously discussed trade-offs between simplicity, which potentially aids adoption, and complexity (sometimes provided by prior art), which potentially provides better coverage. As noted above, the Common Domain Model under FINOS already has a schema for product: https://cdm.finos.org/docs/product-model Is there a reason why FDC3 couldn't adopt this? Additionally, I would question if an RFQ should be a wrapper around a product or a proposed transaction (Order). For example, if I am trading an EFP such as sell ETF/buy Future, I would want quotes for the entire transaction, not just one of the products. Equity Program Trades and Bond Portfolio Trades would be similar since they contain multiple products. |
Describe your change
@mistryvinay here is a first pass at a PR to fulfill the context issues you've raised. Its a draft as it needs attention from an expert in order types/modelling or to be rethought based on the use of the Common Domain Model (CDM) to define the product. I don't propose to complete this PR myself, but thought creating a draft might help get the call rolling... @kriswest
Extends the order, trade and product types to support a notes field.
Extends the product context type to have a type field
Extends the product context type to be able to describe a wider range of order types
Creates an RFQ type that wraps a product.
Preview links:
Related Issue
resolves: #1373
resolves #1374
resolves #1461
Contributor License Agreement
Review Checklist
DesktopAgent
,Channel
,PrivateChannel
,Listener
,Bridging
)?JSDoc comments on interfaces and types should be matched to the main documentation in /docs
Conformance test definitions should cover all required aspects of an FDC3 Desktop Agent implementation, which are usually marked with a MUST keyword, and optional features (SHOULD or MAY) where the format of those features is defined
The Web Connection protocol and Desktop Agent Communication Protocol schemas must be able to support all necessary aspects of the Desktop Agent API, while Bridging must support those aspects necessary for Desktop Agents to communicate with each other
npm run build
) run and the results checked in?Generated code will be found at
/src/api/BrowserTypes.ts
and/or/src/bridging/BridgingTypes.ts
BaseContext
schema applied viaallOf
(as it is in existing types)?title
anddescription
provided for all properties defined in the schema?npm run build
) run and the results checked in?Generated code will be found at
/src/context/ContextTypes.ts