Enhancement Request
Use Case:
At FactSet we have an FDS_TYPE property that we use with contexts to further refine the type of the context. We use this field to determine whether to run extra resolutions on the context and add more properties to the id field. For instrument contexts some examples would include publicCompany, privateCompany, commodity, etf, mutualFund, future, option. We currently place this property inside id, but are wondering if that is the best place to put it. Would it make sense to have an optional top level classification field? Being an object itself with any number of sub properties. Also just want to present the use case and ask if others do anything like this or see value in it.
EDIT: examples have been updated to reflect classification being an object rather than a string following feedback.
EDIT 2: examples have been updated to use classification.name rather than classification.fdc3
Contexts
Instrument
Details
| Property |
Type |
Required |
Example Value |
type |
string |
Yes |
'fdc3.instrument' |
name |
string |
No |
'Fidelity 500 Index Fund' |
id.ticker |
string |
No |
'FXAIX' |
classification |
string |
No |
'mutualFund' |
classification |
object |
No |
{name: 'mutualFund', FDS_TYPE: 'mutualFund', fdc3: 'mutualFund', } |
Example
const instrument = {
type: 'fdc3.instrument',
name: 'Fidelity 500 Index Fund',
id: {
ticker: 'FXAIX',
CUSIP: '315911750',
ISIN: 'US3159117502',
SEDOL: 'B4VF818'
},
//classification: 'mutualFund',
classification: {
//fdc3: 'mutualFund',
name: 'mutualFund',
FDS_TYPE: 'mutualFund'
}
}
Example 2
const instrument = {
type: "fdc3.instrument",
name: "Microsoft",
id: {
ticker: "MSFT",
RIC: "MSFT.OQ",
ISIN: "US5949181045"
},
market: {
MIC: "XNAS"
},
classification: {
//fdc3: "publicCompany",
name: "publicCompany",
XYZ: "company",
CDM: "equity"
}
}
Additional Information
- Conceptually this is similar to supporting more granular
types for contexts, but it wouldn't make sense to actually split off more types and fracture the listener ecosystem.
- If others feel the best place to put this info is in the existing
id field then we can continue doing that.
Enhancement Request
Use Case:
At FactSet we have an
FDS_TYPEproperty that we use with contexts to further refine thetypeof the context. We use this field to determine whether to run extra resolutions on the context and add more properties to theidfield. Forinstrumentcontexts some examples would includepublicCompany, privateCompany, commodity, etf, mutualFund, future, option. We currently place this property insideid, but are wondering if that is the best place to put it. Would it make sense to have an optional top levelclassificationfield? Being an object itself with any number of sub properties. Also just want to present the use case and ask if others do anything like this or see value in it.EDIT: examples have been updated to reflect
classificationbeing an object rather than a string following feedback.EDIT 2: examples have been updated to use
classification.namerather thanclassification.fdc3Contexts
Instrument
Details
type'fdc3.instrument'name'Fidelity 500 Index Fund'id.ticker'FXAIX'classificationstringNo'mutualFund'classificationfdc3: 'mutualFund',}Example
Example 2
Additional Information
types for contexts, but it wouldn't make sense to actually split off more types and fracture the listener ecosystem.idfield then we can continue doing that.