fix-orchestra-spec
fix-orchestra-spec copied to clipboard
Technical specification for FIX Orchestra (machine readable rules of engagement)
Section 1.1 lists a number of objectives that should be reviewed for v1.1, specifically the following: - *Message structure by each scenario, implemented as an extension of the FIX Repository.*...
Orchestra v1.0 spec does not explain this attribute, Schema shows the following: ```xml ```
The specification should include more detailed guidelines for usage of Dublin Core Terms in the metadata section. One issue raised in the MOST working group is to distinguish interfaces files...
The v1.0 spec uses all 3 terms and the difference is unclear. This should be made consistent. Examples: ```xml An internal is a container for elements. It is a reference...
V1.0 points to supplementary documentation for repository and interfaces as follows: > See the separate document “FixRepository2020.html” for a detailed technical reference for the Orchestra and Repository XML schema. >...
In Orchestra version 1.0 abstract metamodel, a field has a type (as well as other attributes such as name and id). Type refers to a datatype. Also, in the metamodel...
Issue entered in https://github.com/FIXTradingCommunity/fix-orchestra/issues/125
Would like to add back in as an optional field the ability to include the name of the field or the name of the component in addition to the id...
Orchestra version 1.0 introduced Concepts. The big idea is that a semantic concept can have different representations in different protocols, even between different versions of FIX. Mapping a concept to...
The DSL specification should tell about datatypes of variables, such as whether they are static or dynamic. My proposal: * Every variable has a FIX datatype so variables are interchangeable...