├── .gitignore ├── LICENSE ├── README.md ├── v1-0-RC1 └── doc │ └── publication │ └── FIX-Simple-Binary-Encoding-Specification-v0.9.2_RC1.pdf ├── v1-0-RC2 └── doc │ └── publication │ └── Simple-Binary-Encoding-Release-Candidate-2.pdf ├── v1-0-RC3 ├── doc │ ├── 00Contents.md │ ├── 00Title.md │ ├── 01Introduction.md │ ├── 02FieldEncoding.md │ ├── 03MessageStructure.md │ ├── 04MessageSchema.md │ ├── 05SchemaExtensionMechanism.md │ ├── 06UsageGuidelines.md │ ├── 07Examples.md │ ├── 08ReleaseNotes.md │ ├── media │ │ └── image1.jpeg │ └── publication │ │ └── Simple-Binary-Encoding-Release-Candidate-3.pdf └── resources │ ├── Examples.xml │ └── SimpleBinary1-0.xsd ├── v1-0-RC4 ├── doc │ ├── 00Contents.md │ ├── 00Title.md │ ├── 01Introduction.md │ ├── 02FieldEncoding.md │ ├── 03MessageStructure.md │ ├── 04MessageSchema.md │ ├── 05SchemaExtensionMechanism.md │ ├── 06UsageGuidelines.md │ ├── 07Examples.md │ ├── 08ReleaseNotes.md │ ├── media │ │ └── image1.jpeg │ └── publication │ │ └── Simple-Binary-Encoding-Release-Candidate-4.pdf └── resources │ ├── Examples.xml │ └── SimpleBinary1-0.xsd ├── v1-0-STANDARD ├── doc │ ├── 01Introduction.md │ ├── 02FieldEncoding.md │ ├── 03MessageStructure.md │ ├── 04MessageSchema.md │ ├── 05SchemaExtensionMechanism.md │ ├── 06UsageGuidelines.md │ ├── 07Examples.md │ ├── FIXDisclaimerTechStd.md │ ├── FIX_TechStd_Style_MASTER.docx │ ├── ISOBiblio.md │ ├── ISOCopyright.md │ ├── ISOForeword.md │ ├── ISOIntro.md │ ├── ISO_TechStd_Style_MASTER.docx │ ├── JTC1Biblio.md │ ├── JTC1Copyright.md │ ├── JTC1Foreword.md │ ├── JTC1Intro.md │ ├── JTC1_TechStd_Style_MASTER.docx │ ├── SBE.cmd │ ├── SBE.sh │ ├── SBE.yaml │ ├── SBE_ISO.yaml │ ├── SBE_JTC1.yaml │ ├── media │ │ └── image1.jpeg │ └── publication │ │ ├── SBEONLINE_PROD_with_20180727_errata.html │ │ ├── SBEONLINE_PROD_with_November_2020_errata.html │ │ ├── Simple Binary Encoding - Technical Specification version1-0.docx │ │ ├── Simple Binary Encoding - Technical Specification version1-0.pdf │ │ ├── Simple Binary Encoding Technical Proposal V1.0 with Errata Nov 2020.docx │ │ ├── Simple-Binary-Encoding-Draft-Standard-v1.0.pdf │ │ ├── Simple-Binary-Encoding-Technical-Specification-version1-0-with-20180727-errata.docx │ │ ├── Simple-Binary-Encoding-Technical-Specification-version1-0-with-20180727-errata.pdf │ │ ├── Simple_Binary_Encoding_V1.0_with_Errata_November_2020.docx │ │ ├── Simple_Binary_Encoding_V1.0_with_Errata_November_2020.pdf │ │ ├── Simple_Binary_Encoding_V1.0_with_Errata_November_2020_changetracked.docx │ │ └── Simple_Binary_Encoding_V1.0_with_Errata_November_2020_changetracked.pdf └── resources │ ├── Examples.xml │ └── sbe.xsd ├── v2-0-RC1 ├── doc │ ├── 00Contents.md │ ├── 00Title.md │ ├── 01Introduction.md │ ├── 02FieldEncoding.md │ ├── 03MessageStructure.md │ ├── 04MessageSchema.md │ ├── 05SchemaExtensionMechanism.md │ ├── 06UsageGuidelines.md │ ├── 07Examples.md │ ├── 08ReleaseNotes.md │ ├── media │ │ └── image1.jpeg │ └── publication │ │ └── Simple-Binary-Encoding-Technical-Specification-v2-RC1.pdf └── resources │ ├── Examples.xml │ └── sbe.xsd ├── v2-0-RC2 ├── doc │ ├── 00Contents.md │ ├── 00Title.md │ ├── 01Introduction.md │ ├── 02FieldEncoding.md │ ├── 03MessageStructure.md │ ├── 04MessageSchema.md │ ├── 05SchemaExtensionMechanism.md │ ├── 06UsageGuidelines.md │ ├── 07Examples.md │ ├── 08ReleaseNotes.md │ ├── FIXDisclaimerTechStd.md │ ├── FIX_TechStd_Style_MASTER.docx │ ├── SBE.sh │ ├── SBE.yaml │ ├── media │ │ └── image1.jpeg │ └── publication │ │ └── Simple-Binary-Encoding-v2-RC2.pdf └── resources │ ├── xml │ ├── examples.xml │ ├── messages-include.xml │ └── types-include.xml │ └── xsd │ └── sbe-2.0rc2.xsd └── v2-0-RC3 ├── doc ├── 00Contents.md ├── 00Title.md ├── 01Introduction.md ├── 02FieldEncoding.md ├── 03MessageStructure.md ├── 04MessageSchema.md ├── 05SchemaExtensionMechanism.md ├── 06UsageGuidelines.md ├── 07Examples.md ├── 08ReleaseNotes.md ├── FIXDisclaimerTechStd.md ├── FIX_TechStd_Style_MASTER.docx ├── SBE.sh ├── SBE.yaml └── media │ └── image1.jpeg └── resources ├── xml ├── examples.xml ├── messages-include.xml └── types-include.xml └── xsd └── sbe-2.0rc3.xsd /.gitignore: -------------------------------------------------------------------------------- 1 | .settings 2 | .project 3 | target 4 | .DS_Store 5 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fix-simple-binary-encoding/3dca4cee4e9afb2a1dee624f2bb68f8bc7525e25/LICENSE -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # fix-simple-binary-encoding 2 | 3 | This project contains specifications and resources for Simple Binary Encoding (SBE). 4 | SBE is a FIX standard for binary message encoding. 5 | 6 | ## *News* 7 | 8 | [application/sbe](https://www.iana.org/assignments/media-types/application/sbe) has been registered as a media type (formerly MIME type) at Internet Assigned Numbers Authority (IANA). A media type defines the format of the contents of an Internet message. 9 | 10 | ## Protocol stack 11 | SBE is part of a family of protocols created by the High Performance Working Group 12 | of the FIX Trading Community. SBE is a presentation layer protocol (layer 6). 13 | 14 | ## Versions 15 | 16 | ### Planned Lifecycle 17 | 18 | The planned lifecycle of this project is to roll out new features in a series of release candidates. After each release candidate is approved, it will be exposed to public review. Issues may be entered here in GitHub or in a discussion forum on the FIX Trading Community site. When a version is considered complete, the last release candidate will be promoted to Draft Standard. Following further public review, a Draft Standard may be promoted to the final specification for that version. Only minor errata are permitted. To reach the final stage, the Draft Standard must be reviewed for no less than 6 months, and at least two interoperable implementations must be certified. That version is henceforth immutable. 19 | 20 | SBE version 1.0 has reached the final technical specification stage while release candidates have been developed for proposed version 2.0. 21 | 22 | ### Version 2.0 Release Candidate 2 23 | 24 | Version 2.0 RC2 was approved by the Global Technical Committee on August 15, 2019 for 90 day public review. 25 | 26 | Themes of this release: 27 | 28 | * Clarification about single-byte character sets 29 | * Improvement of the XML schema, including support for XInclude 30 | 31 | ### Version 2.0 Release Candidate 1 32 | 33 | Version 2.0 RC1 was approved by the Global Technical Committee on August 16, 2018 for 90 day public review. Features were added due to popular demand. Because it is not interoperable with version 1.0 due to minor wire format changes, it was designated as a major version. 34 | 35 | Themes of this release: 36 | 37 | * Further enhancements to the schema extension mechanism 38 | * Improvement of the XML schema 39 | 40 | ### Version: 1.0 Technical Specification 41 | Version 1.0 Draft Standard was promoted to SBE version 1.0 Technical Specification by the Global Technical Committee on Feb. 9, 2016. This is the final specification of version 1.0. 42 | 43 | The standard met these criteria for promotion: 44 | * More than 6 months public review. During the period, some minor errors were found, and the errata were incorporated into the final specification. Thanks to users who detected those errors. 45 | 46 | * At least two interoperable implementations. This was demonstrated with the conformance test suite described below. 47 | 48 | SBE standards are available here in GitHub and on the [FIX Trading Community](http://www.fixtradingcommunity.org/pg/structure/tech-specs/simple-binary-encoding) site. 49 | 50 | SBE version 1.0 specification with errata was posted July 27, 2018. 51 | 52 | #### XML namespace 53 | The XML namespace for SBE version 1.0 message schemas is [http://fixprotocol.io/2016/sbe](http://fixprotocol.io/2016/sbe). 54 | 55 | ### Participation 56 | All users are encouraged to contribute, especially by reviewing proposed changes in the form of pull requests. Your feedback counts. 57 | 58 | Interested parties who wish to participate in the FIX High Performance Working Group should contact fix@fixtrading.org and state that your interest is in SBE, which sometimes meets as a subgroup. Membership in FIX Trading Community is not required to participate in technical working groups. 59 | 60 | ### Conformance test suite 61 | The [SBE Conformance project](https://github.com/FIXTradingCommunity/fix-sbe-conformance) provides a conformance test suite to verify interoperability of SBE implementations. All implementors are invited to demonstrate their conformance to the standard. 62 | 63 | ## License 64 | FIX Simple Binary Encoding specifications are © Copyright 2014-2020 FIX Protocol Ltd. 65 | 66 | Creative Commons License
FIX Simple Binary Encoding by FIX Protocol Ltd. is licensed under a Creative Commons Attribution-NoDerivatives 4.0 International License.
Based on a work at https://github.com/FIXTradingCommunity/fix-simple-binary-encoding 67 | -------------------------------------------------------------------------------- /v1-0-RC1/doc/publication/FIX-Simple-Binary-Encoding-Specification-v0.9.2_RC1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fix-simple-binary-encoding/3dca4cee4e9afb2a1dee624f2bb68f8bc7525e25/v1-0-RC1/doc/publication/FIX-Simple-Binary-Encoding-Specification-v0.9.2_RC1.pdf -------------------------------------------------------------------------------- /v1-0-RC2/doc/publication/Simple-Binary-Encoding-Release-Candidate-2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fix-simple-binary-encoding/3dca4cee4e9afb2a1dee624f2bb68f8bc7525e25/v1-0-RC2/doc/publication/Simple-Binary-Encoding-Release-Candidate-2.pdf -------------------------------------------------------------------------------- /v1-0-RC3/doc/00Contents.md: -------------------------------------------------------------------------------- 1 | Contents 2 | ======== 3 | 4 | [Title](00Title.md) 5 | 6 | [1. Introduction](01Introduction.md) 7 | 8 | [2. Field Encoding](02FieldEncoding.md) 9 | 10 | [3. Message Structure](03MessageStructure.md) 11 | 12 | [4. Message Schema](04MessageSchema.md) 13 | 14 | [5. Schema Extension Mechanism](05SchemaExtensionMechanism.md) 15 | 16 | [6. Usage Guidelines](06UsageGuidelines.md) 17 | 18 | [7. Examples](07Examples.md) 19 | 20 | [8 .Release Notes](08ReleaseNotes.md) -------------------------------------------------------------------------------- /v1-0-RC3/doc/00Title.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fix-simple-binary-encoding/3dca4cee4e9afb2a1dee624f2bb68f8bc7525e25/v1-0-RC3/doc/00Title.md -------------------------------------------------------------------------------- /v1-0-RC3/doc/01Introduction.md: -------------------------------------------------------------------------------- 1 | Introduction 2 | ========================================================================================================================================================= 3 | 4 | FIX Simple Binary Encoding (SBE) targets high performance trading 5 | systems. It is optimized for low latency of encoding and decoding while 6 | keeping bandwidth utilization reasonably small. For compatibility, it is 7 | intended to represent all FIX semantics. 8 | 9 | This encoding specification describes the wire protocol for messages. 10 | Thus, it provides a standard for interoperability between communicating 11 | parties. Users are free to implement the standard in a way that best 12 | suits their needs. 13 | 14 | The encoding standard is complimentary to other FIX standards for 15 | session protocol and application level behavior. 16 | 17 | Binary type system 18 | ---------------------------------------------------------------------------------------------------------------- 19 | 20 | In order to support traditional FIX semantics, all the documented field 21 | types are supported. However, instead of printable character 22 | representations of tag-value encoding, the type system binds to native 23 | binary data types, and defines derived types as needed. 24 | 25 | The binary type system has been enhanced in these ways: 26 | 27 | - Provides a means to specify precision of decimal numbers and 28 | timestamps, as well as valid ranges of numbers. 29 | 30 | - Differentiates fixed-length character arrays from variable-length 31 | strings. Allows a way to specify the minimum and maximum length of 32 | strings that an application can accept. 33 | 34 | - Provides a consistent system of enumerations, Boolean switches and 35 | multiple-choice fields. 36 | 37 | Design principles 38 | --------------------------------------------------------------------------------------------------------------- 39 | 40 | The message design strives for direct data access without complex 41 | transformations or conditional logic. This is achieved by: 42 | 43 | - Usage of native binary data types and simple types derived from 44 | native binaries, such as prices and timestamps. 45 | 46 | - Preference for fixed positions and fixed length fields, supporting 47 | direct access to data and avoiding the need for management of heaps 48 | of variable-length elements which must be sequentially processed. 49 | 50 | Message schema 51 | ------------------------------------------------------------------------------------------------------------ 52 | 53 | This standard describes how fields are encoded and the general structure 54 | of messages. The content of a message type is specified by a message 55 | schema. A message schema tells which fields belong to a message and 56 | their location within a message. Additionally, the metadata describes 57 | valid value ranges and information that need not be sent on the wire, 58 | such as constant values. 59 | 60 | Message schemas may be based on standard FIX message specifications, or 61 | may be customized as needed by agreement between counterparties. 62 | 63 | Glossary 64 | ------------------------------------------------------------------------------------------------------ 65 | 66 | **Data type** - A field type with its associated encoding attributes, 67 | including backing primitive types and valid values or range. Some types 68 | have additional attributes, e.g. epoch of a date. 69 | 70 | **Encoding** - a message format for interchange. The term is commonly used 71 | to mean the conversion of one data format to another, such as text to 72 | binary. However, Simple Binary Encoding strives to use native binary 73 | data types in order to make conversion unnecessary, or at least trivial. 74 | Encoding also refers to the act of formatting a message, as opposed to 75 | decoding. 76 | 77 | **Message schema** - metadata that specifies messages and their data 78 | types and identifiers. Message schemas may be disseminated out of band. 79 | For Simple Binary Encoding, message schemas are expressed as an XML 80 | document that conforms to an XML schema that is published as part of 81 | this standard. 82 | 83 | **Message template** - metadata that specifies the fields that belong to 84 | one particular message type. A message template is contained by a 85 | message schema. 86 | 87 | **Session protocol** - a protocol concerned with the reliable delivery of 88 | messages over a transport. FIX protocol makes a distinction between 89 | session protocol and the encoding of a message payload, as described by 90 | this document. See the specifications section of FIX protocol web site 91 | for supported protocols. The original FIX session protocol is known as 92 | FIXT. 93 | 94 | **XML schema** - defines the elements and attributes that may appear in an 95 | XML document. The SBE message schema is defined in W3C (XSD) schema 96 | language since it is the most widely adopted format for XML schemas. 97 | 98 | Documentation 99 | ----------------------------------------------------------------------------------------------------------- 100 | 101 | This document explains: 102 | 103 | - The binary type system for field encoding 104 | 105 | - Message structure, including field arrangement, repeating groups, 106 | and relationship to a message header that may be provided by a 107 | session protocol. 108 | 109 | - The Simple Binary Encoding message schema. 110 | 111 | ### Specification terms 112 | 113 | These key words in this document are to be interpreted as described in 114 | [Internet Engineering Task Force RFC2119](http://www.apps.ietf.org/rfc/rfc2119.html). These terms indicate 115 | an absolute requirement for implementations of the standard: "**must**", 116 | or "**required**". 117 | 118 | This term indicates an absolute prohibition: "**must not**". 119 | 120 | These terms indicate that a feature is allowed by the standard but not 121 | required: "**may**", "**optional**". An implementation that does not 122 | provide an optional feature must be prepared to interoperate with one 123 | that does. 124 | 125 | These terms give guidance, recommendation or best practices: 126 | "**should**" or "**recommended**". A recommended choice among 127 | alternatives is described as "**preferred**". 128 | 129 | These terms give guidance that a practice is not recommended: "**should not**" 130 | or "**not recommended**". 131 | 132 | ### Document format 133 | 134 | In this document, these formats are used for technical specifications 135 | and data examples. 136 | 137 | This is a sample encoding specification 138 | 139 | ```xml 140 | 141 | ``` 142 | 143 | This is sample data as it would be transmitted on the wire 144 | 145 | `10270000` 146 | 147 | References 148 | ------------------------------------------------------------------------------------------------------------------------------------------------------- 149 | 150 | ### Related FIX Standards 151 | 152 | *Simple Open Framing Header*, FIX Protocol, Limited. Release Candidate 1 153 | specification has been published at 154 | 155 | 156 | For FIX semantics, see the current FIX message specification, which is 157 | currently [FIX 5.0 Service Pack 2](http://www.fixtradingcommunity.org/pg/structure/tech-specs/fix-version/50-service-pack-2) 158 | with Extension Packs. 159 | 160 | ### Dependencies on other standards 161 | 162 | SBE is dependent on several industry standards. Implementations must 163 | conform to these standards to interoperate. Therefore, they are 164 | normative for SBE. 165 | 166 | [IEEE 754-2008](http://ieeexplore.ieee.org/servlet/opac?punumber=4610933) A 167 | Standard for Binary Floating-Point Arithmetic 168 | 169 | [ISO 639-1:2002](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=22109) 170 | Codes for the representation of names of languages - Part 1: Alpha-2 171 | code 172 | 173 | [ISO 3166-1:2013](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63545) 174 | Codes for the representation of names of countries and their 175 | subdivisions - Part 1: Country codes 176 | 177 | [ISO 4217:2008](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=46121) 178 | Codes for the representation of currencies and funds 179 | 180 | [ISO 8601:2004](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=40874) 181 | Data elements and interchange formats - Information interchange - 182 | Representation of dates and times 183 | 184 | [ISO 10383:2012](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=61067) 185 | Securities and related financial instruments - Codes for exchanges and 186 | market identification (MIC) 187 | 188 | XML 1.1 schema standards are located here [W3C XML Schema](http://www.w3.org/XML/Schema.html#dev) 189 | -------------------------------------------------------------------------------- /v1-0-RC3/doc/05SchemaExtensionMechanism.md: -------------------------------------------------------------------------------- 1 | Schema Extension Mechanism 2 | ===================================================================================================================================================================================================================================================================== 3 | 4 | Objective 5 | --------- 6 | 7 | It is not always practical to update all message publishers and 8 | consumers simultaneously. Within certain constraints, message schemas 9 | and wire formats can be extended in a controlled way. Consumers using an 10 | older version of a schema should be compatible if interpretation of 11 | added fields or messages is not required for business processing. 12 | 13 | ### Constraints 14 | 15 | Compatibility is only ensured under these conditions: 16 | 17 | - Fields may be added to either the root of a message or to a 18 | repeating group, but in each case, they must be appended to end of a 19 | block. 20 | 21 | - Existing fields cannot change data type or move within a message. 22 | 23 | - A repeating group may be added, but only after existing groups and 24 | if there are no subsequent variable data elements at the end of the 25 | message. 26 | 27 | - A variable data element may be added, but only after existing groups 28 | and data. 29 | 30 | - Message header encoding cannot change. 31 | 32 | Changes that break those constraints require consumers to update to the 33 | current schema used by publishers. In general, metadata changes such as 34 | name or description corrections do not break compatibility so long as 35 | wire format does not change. 36 | 37 | Message schema features for extension 38 | ------------------------------------- 39 | 40 | ### Schema version 41 | 42 | The `` root element contains a version number attribute. 43 | By default, version is zero, the initial version of a message schema. 44 | Each time a message schema is changed, the version number is 45 | incremented. 46 | 47 | Version applies to the schema as a whole, not to individual elements. 48 | Version is sent in the message header so the consumer can determine 49 | which version of the message schema was used to encode the message. 50 | 51 | See section 4.3.1 above for schema attributes. 52 | 53 | ### Since version 54 | 55 | When a new field, group or message is added to a message schema, the 56 | extension may be documented by adding a sinceVersion attribute to the 57 | element. The sinceVersion attribute tells in which schema version the 58 | element was added. This attribute remains the same for that element for 59 | the lifetime of the schema. This attribute is for documentation purposes 60 | only, it is not sent on the wire. 61 | 62 | Over time, multiple extensions may be added to a message schema. New 63 | fields must be appended following earlier extensions. By documenting 64 | when each element was added, it possible to verify that extensions were 65 | appended in proper order. 66 | 67 | ### Block length 68 | 69 | The length of the root level of the message may optionally be documented 70 | on a `` element in the schema using the blockLength attribute. 71 | See section 4.5.3 above for message attributes. If not set in the 72 | schema, block length of the message root is the sum of its field 73 | lengths. Whether it is set in the schema or not, the block length is 74 | sent on the wire to consumers. 75 | 76 | Likewise, a repeating group has a blockLength attribute to tell how much 77 | space is reserved for group entries, and the value is sent on the wire. 78 | It is encoded in the schema as part of the NumInGroup field encoding. 79 | See section 3.4.8.2 above. 80 | 81 | ### Deprecated elements 82 | 83 | A message schema may document obsolete elements, such as messages, 84 | fields, and valid values of enumerations with deprecated attribute. 85 | Updated applications should not publish deprecated messages or values, 86 | but declarations may remain in the message schema during a staged 87 | migration to replacement message layouts. 88 | 89 | Wire format features for extension 90 | ---------------------------------- 91 | 92 | ### Message size 93 | 94 | It is assumed that a either message boundaries are delimited by a 95 | transport or session protocol header conveys the size of the whole 96 | message. See section 3.1 above. This enables a consumer to properly 97 | frame messages even when the message has been lengthened in a later 98 | version of the schema. 99 | 100 | ### Block size 101 | 102 | The length of the root level of the message is sent on the wire in the 103 | SBE message header. See section 3.2.2 above. Therefore, if new fields 104 | were appended in a later version of the schema, the consumer would still 105 | know how many octets to consume to find the next message element, such 106 | as repeating group or variable-length Data field. Without the current 107 | schema version, the consumer cannot interpret the new fields, but it 108 | does not break parsing of earlier fields. 109 | 110 | Likewise, block size of a repeating group is conveyed in the NumInGroup 111 | encoding. 112 | 113 | Message schema extension example 114 | -------------------------------- 115 | 116 | Initial version of a message schema 117 | 118 | ```xml 119 | 120 | 121 | 122 | 123 | 124 | 125 | 126 | 127 | 128 | 129 | ``` 130 | 131 | Second version - a new message is added 132 | 133 | ```xml 134 | 136 | 137 | 138 | 139 | 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 150 | 151 | 152 | 153 | ``` 154 | 155 | Third version - a field is added 156 | 157 | ```xml 158 | 160 | 161 | 162 | 163 | 165 | 167 | 168 | 169 | 170 | 171 | 173 | 174 | 175 | 177 | 178 | 179 | 180 | ``` 181 | -------------------------------------------------------------------------------- /v1-0-RC3/doc/06UsageGuidelines.md: -------------------------------------------------------------------------------- 1 | Usage Guidelines 2 | ================ 3 | 4 | Identifier encodings 5 | ------------------------------------------------------------------------------------------------------------------- 6 | 7 | FIX specifies request and entity identifiers as String type. Common 8 | practice is to specify an identifier field as fixed-length character of 9 | a certain size. 10 | 11 | Optionally, a message schema may restrict such identifiers to numeric 12 | encodings. 13 | 14 | Example of an identifier field with character encoding 15 | 16 | ```xml 17 | 18 | 19 | 21 | ``` 22 | 23 | Example of an identifier field with numeric encoding 24 | 25 | ```xml 26 | 27 | 28 | 30 | ``` 31 | -------------------------------------------------------------------------------- /v1-0-RC3/doc/08ReleaseNotes.md: -------------------------------------------------------------------------------- 1 | Release Notes 2 | ============= 3 | 4 | Release Candidate 3 5 | ------------------- 6 | 7 | This is a summary of document changes to Release Candidate 3 from RC2. 8 | Changes in this release were intended only as clarifications or to add 9 | capabilities. Message schemas that conformed to the RC2 specification 10 | should still conform to the RC3 wire format. 11 | 12 | **Section 1** 13 | 14 | References section expanded. 15 | 16 | **Section 2** 17 | 18 | - Statement added that non-FIX data types should not carry a 19 | semanticType attribute in a message schema. 20 | 21 | - String encoding section split into two sections for strings (text 22 | fields) and data (non-character data) to clarify the distinction. 23 | Both text and non-text can be either fixed-length `` or 24 | variable-length ``. 25 | 26 | - Timestamp encoding enhanced to allow time unit to either be 27 | specified as a constant in a message schema or to be serialized on 28 | the wire. 29 | 30 | **Section 3** 31 | 32 | Message structure is enhanced to allow variable-length `` elements 33 | within a repeating group entry. 34 | 35 | **Section 4** 36 | 37 | Message schema XSD updated to support `` in repeating groups and 38 | for various other refinements 39 | 40 | **Section 5** 41 | 42 | - Statements added to say whole repeating groups or variable data may 43 | be added to a message without breaking compatibility so long as the 44 | added elements are at the end of a message. 45 | 46 | - Added deprecated schema attribute to mark obsolete elements. 47 | 48 | **Section 6** 49 | 50 | No change 51 | 52 | **Section 7** 53 | 54 | Examples updated to use Simple Open Framing Header. 55 | 56 | **Section 8** 57 | 58 | Release notes added. 59 | 60 | -------------------------------------------------------------------------------- /v1-0-RC3/doc/media/image1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fix-simple-binary-encoding/3dca4cee4e9afb2a1dee624f2bb68f8bc7525e25/v1-0-RC3/doc/media/image1.jpeg -------------------------------------------------------------------------------- /v1-0-RC3/doc/publication/Simple-Binary-Encoding-Release-Candidate-3.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fix-simple-binary-encoding/3dca4cee4e9afb2a1dee624f2bb68f8bc7525e25/v1-0-RC3/doc/publication/Simple-Binary-Encoding-Release-Candidate-3.pdf -------------------------------------------------------------------------------- /v1-0-RC3/resources/Examples.xml: -------------------------------------------------------------------------------- 1 | 2 | 7 | 8 | 9 | 10 | 12 | 13 | 15 | 16 | 17 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | -3 39 | 40 | 41 | 42 | 43 | 0 44 | 45 | 46 | 0 47 | 1 48 | 2 49 | 4 50 | 6 51 | 52 | 53 | 0 54 | 3 55 | 4 56 | 5 57 | 6 58 | 8 59 | A 60 | F 61 | 62 | 63 | 0 64 | 1 65 | 2 66 | 3 67 | 4 68 | 6 69 | 8 70 | A 71 | E 72 | 73 | 74 | 1 75 | 2 76 | 3 77 | 4 78 | 79 | 80 | 1 81 | 2 82 | 83 | 84 | 86 | 88 | 90 | 91 | 92 | 94 | 96 | 98 | 100 | 102 | 104 | 106 | 108 | 110 | 112 | 114 | 115 | 117 | 119 | 120 | 121 | 123 | 125 | 127 | 129 | 131 | 133 | 135 | 137 | 139 | 141 | 142 | -------------------------------------------------------------------------------- /v1-0-RC4/doc/00Contents.md: -------------------------------------------------------------------------------- 1 | Contents 2 | ======== 3 | 4 | [Title](00Title.md) 5 | 6 | [1. Introduction](01Introduction.md) 7 | 8 | [2. Field Encoding](02FieldEncoding.md) 9 | 10 | [3. Message Structure](03MessageStructure.md) 11 | 12 | [4. Message Schema](04MessageSchema.md) 13 | 14 | [5. Schema Extension Mechanism](05SchemaExtensionMechanism.md) 15 | 16 | [6. Usage Guidelines](06UsageGuidelines.md) 17 | 18 | [7. Examples](07Examples.md) 19 | 20 | [8. Release Notes](08ReleaseNotes.md) -------------------------------------------------------------------------------- /v1-0-RC4/doc/00Title.md: -------------------------------------------------------------------------------- 1 | ![](./media/image1.jpeg) 2 | 3 | FIX Simple Binary Encoding 4 | ========================== 5 | 6 | Technical Specification 7 | 8 | Working Draft for potential Release Candidate 4 9 | 10 | **THIS DOCUMENT IS A RELEASE CANDIDATE FOR A PROPOSED FIX TECHNICAL 11 | STANDARD. A RELEASE CANDIDATE HAS BEEN APPROVED BY THE GLOBAL TECHNICAL 12 | COMMITTEE AS AN INITIAL STEP IN CREATING A NEW FIX TECHNICAL STANDARD. 13 | POTENTIAL ADOPTERS ARE STRONGLY ENCOURAGED TO BEGIN WORKING WITH THE 14 | RELEASE CANDIDATE AND TO PROVIDE FEEDBACK TO THE GLOBAL TECHNICAL 15 | COMMITTEE AND THE WORKING GROUP THAT SUBMITTED THE PROPOSAL. THE 16 | FEEDBACK TO THE RELEASE CANDIDATE WILL DETERMINE IF ANOTHER REVISION AND 17 | RELEASE CANDIDATE IS NECESSARY OR IF THE RELEASE CANDIDATE CAN BE 18 | PROMOTED TO BECOME A FIX TECHNICAL STANDARD DRAFT.** 19 | 20 | **©Copyright 2015-2016 FIX Protocol Limited** 21 | -------------------------------------------------------------------------------- /v1-0-RC4/doc/01Introduction.md: -------------------------------------------------------------------------------- 1 | Introduction 2 | ========================================================================================================================================================= 3 | 4 | FIX Simple Binary Encoding (SBE) targets high performance trading 5 | systems. It is optimized for low latency of encoding and decoding while 6 | keeping bandwidth utilization reasonably small. For compatibility, it is 7 | intended to represent all FIX semantics. 8 | 9 | This encoding specification describes the wire protocol for messages. 10 | Thus, it provides a standard for interoperability between communicating 11 | parties. Users are free to implement the standard in a way that best 12 | suits their needs. 13 | 14 | The encoding standard is complimentary to other FIX standards for 15 | session protocol and application level behavior. 16 | 17 | Binary type system 18 | ---------------------------------------------------------------------------------------------------------------- 19 | 20 | In order to support traditional FIX semantics, all the documented field 21 | types are supported. However, instead of printable character 22 | representations of tag-value encoding, the type system binds to native 23 | binary data types, and defines derived types as needed. 24 | 25 | The binary type system has been enhanced in these ways: 26 | 27 | - Provides a means to specify precision of decimal numbers and 28 | timestamps, as well as valid ranges of numbers. 29 | 30 | - Differentiates fixed-length character arrays from variable-length 31 | strings. Allows a way to specify the minimum and maximum length of 32 | strings that an application can accept. 33 | 34 | - Provides a consistent system of enumerations, Boolean switches and 35 | multiple-choice fields. 36 | 37 | Design principles 38 | --------------------------------------------------------------------------------------------------------------- 39 | 40 | The message design strives for direct data access without complex 41 | transformations or conditional logic. This is achieved by: 42 | 43 | - Usage of native binary data types and simple types derived from 44 | native binaries, such as prices and timestamps. 45 | 46 | - Preference for fixed positions and fixed length fields, supporting 47 | direct access to data and avoiding the need for management of heaps 48 | of variable-length elements which must be sequentially processed. 49 | 50 | Message schema 51 | ------------------------------------------------------------------------------------------------------------ 52 | 53 | This standard describes how fields are encoded and the general structure 54 | of messages. The content of a message type is specified by a message 55 | schema. A message schema tells which fields belong to a message and 56 | their location within a message. Additionally, the metadata describes 57 | valid value ranges and information that need not be sent on the wire, 58 | such as constant values. 59 | 60 | Message schemas may be based on standard FIX message specifications, or 61 | may be customized as needed by agreement between counterparties. 62 | 63 | Glossary 64 | ------------------------------------------------------------------------------------------------------ 65 | 66 | **Data type** - A field type with its associated encoding attributes, 67 | including backing primitive types and valid values or range. Some types 68 | have additional attributes, e.g. epoch of a date. 69 | 70 | **Encoding** - a message format for interchange. The term is commonly used 71 | to mean the conversion of one data format to another, such as text to 72 | binary. However, Simple Binary Encoding strives to use native binary 73 | data types in order to make conversion unnecessary, or at least trivial. 74 | Encoding also refers to the act of formatting a message, as opposed to 75 | decoding. 76 | 77 | **Message schema** - metadata that specifies messages and their data 78 | types and identifiers. Message schemas may be disseminated out of band. 79 | For Simple Binary Encoding, message schemas are expressed as an XML 80 | document that conforms to an XML schema that is published as part of 81 | this standard. 82 | 83 | **Message template** - metadata that specifies the fields that belong to 84 | one particular message type. A message template is contained by a 85 | message schema. 86 | 87 | **Session protocol** - a protocol concerned with the reliable delivery of 88 | messages over a transport. FIX protocol makes a distinction between 89 | session protocol and the encoding of a message payload, as described by 90 | this document. See the specifications section of FIX protocol web site 91 | for supported protocols. The original FIX session protocol is known as 92 | FIXT. 93 | 94 | **XML schema** - defines the elements and attributes that may appear in an 95 | XML document. The SBE message schema is defined in W3C (XSD) schema 96 | language since it is the most widely adopted format for XML schemas. 97 | 98 | Documentation 99 | ----------------------------------------------------------------------------------------------------------- 100 | 101 | This document explains: 102 | 103 | - The binary type system for field encoding 104 | 105 | - Message structure, including field arrangement, repeating groups, 106 | and relationship to a message header that may be provided by a 107 | session protocol. 108 | 109 | - The Simple Binary Encoding message schema. 110 | 111 | ### Specification terms 112 | 113 | These key words in this document are to be interpreted as described in 114 | [Internet Engineering Task Force RFC2119](http://www.apps.ietf.org/rfc/rfc2119.html). These terms indicate 115 | an absolute requirement for implementations of the standard: "**must**", 116 | or "**required**". 117 | 118 | This term indicates an absolute prohibition: "**must not**". 119 | 120 | These terms indicate that a feature is allowed by the standard but not 121 | required: "**may**", "**optional**". An implementation that does not 122 | provide an optional feature must be prepared to interoperate with one 123 | that does. 124 | 125 | These terms give guidance, recommendation or best practices: 126 | "**should**" or "**recommended**". A recommended choice among 127 | alternatives is described as "**preferred**". 128 | 129 | These terms give guidance that a practice is not recommended: "**should not**" 130 | or "**not recommended**". 131 | 132 | ### Document format 133 | 134 | In this document, these formats are used for technical specifications 135 | and data examples. 136 | 137 | This is a sample encoding specification 138 | 139 | ```xml 140 | 141 | ``` 142 | 143 | This is sample data as it would be transmitted on the wire 144 | 145 | `10270000` 146 | 147 | References 148 | ------------------------------------------------------------------------------------------------------------------------------------------------------- 149 | 150 | ### Related FIX Standards 151 | 152 | *Simple Open Framing Header*, FIX Protocol, Limited. Release Candidate 1 153 | specification has been published at 154 | 155 | 156 | For FIX semantics, see the current FIX message specification, which is 157 | currently [FIX 5.0 Service Pack 2](http://www.fixtradingcommunity.org/pg/structure/tech-specs/fix-version/50-service-pack-2) 158 | with Extension Packs. 159 | 160 | ### Dependencies on other standards 161 | 162 | SBE is dependent on several industry standards. Implementations must 163 | conform to these standards to interoperate. Therefore, they are 164 | normative for SBE. 165 | 166 | [IEEE 754-2008](http://ieeexplore.ieee.org/servlet/opac?punumber=4610933) A 167 | Standard for Binary Floating-Point Arithmetic 168 | 169 | [ISO 639-1:2002](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=22109) 170 | Codes for the representation of names of languages - Part 1: Alpha-2 171 | code 172 | 173 | [ISO 3166-1:2013](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63545) 174 | Codes for the representation of names of countries and their 175 | subdivisions - Part 1: Country codes 176 | 177 | [ISO 4217:2008](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=46121) 178 | Codes for the representation of currencies and funds 179 | 180 | [ISO 8601:2004](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=40874) 181 | Data elements and interchange formats - Information interchange - 182 | Representation of dates and times 183 | 184 | [ISO 10383:2012](http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=61067) 185 | Securities and related financial instruments - Codes for exchanges and 186 | market identification (MIC) 187 | 188 | XML 1.1 schema standards are located here [W3C XML Schema](http://www.w3.org/XML/Schema.html#dev) 189 | -------------------------------------------------------------------------------- /v1-0-RC4/doc/05SchemaExtensionMechanism.md: -------------------------------------------------------------------------------- 1 | Schema Extension Mechanism 2 | ===================================================================================================================================================================================================================================================================== 3 | 4 | Objective 5 | --------- 6 | 7 | It is not always practical to update all message publishers and 8 | consumers simultaneously. Within certain constraints, message schemas 9 | and wire formats can be extended in a controlled way. Consumers using an 10 | older version of a schema should be compatible if interpretation of 11 | added fields or messages is not required for business processing. 12 | 13 | This specification only details compatibility at the presentation layer. It does not relieve application developers of any responsibility for carefully planning a migration strategy and for handling exceptions at the application layer. 14 | 15 | ### Constraints 16 | 17 | Compatibility is only ensured under these conditions: 18 | 19 | - Fields may be added to either the root of a message or to a 20 | repeating group, but in each case, they must be appended to end of a 21 | block. 22 | 23 | - Existing fields cannot change data type or move within a message. 24 | 25 | - A repeating group may be added, but only after existing groups and 26 | if there are no subsequent variable data elements at the end of the 27 | message. 28 | 29 | - A variable data element may be added, but only after existing groups 30 | and data. 31 | 32 | - Message header encoding cannot change. 33 | 34 | - In general, metadata changes such as name or description corrections do not break compatibility so long as 35 | wire format does not change. 36 | 37 | Changes that break those constraints require consumers to update to the 38 | current schema used by publishers. An message template that has changed in an incompatible way must be assinged a new template "id" attribute. 39 | 40 | Message schema features for extension 41 | ------------------------------------- 42 | 43 | ### Schema version 44 | 45 | The `` root element contains a version number attribute. 46 | By default, version is zero, the initial version of a message schema. 47 | Each time a message schema is changed, the version number is 48 | incremented. 49 | 50 | Version applies to the schema as a whole, not to individual elements. 51 | Version is sent in the message header so the consumer can determine 52 | which version of the message schema was used to encode the message. 53 | 54 | See section 4.3.1 above for schema attributes. 55 | 56 | ### Since version 57 | 58 | When a new field, enumeration value, group or message is added to a message schema, the 59 | extension may be documented by adding a sinceVersion attribute to the 60 | element. The sinceVersion attribute tells in which schema version the 61 | element was added. This attribute remains the same for that element for 62 | the lifetime of the schema. This attribute is for documentation purposes 63 | only, it is not sent on the wire. 64 | 65 | Over time, multiple extensions may be added to a message schema. New 66 | fields must be appended following earlier extensions. By documenting 67 | when each element was added, it possible to verify that extensions were 68 | appended in proper order. 69 | 70 | ### Block length 71 | 72 | The length of the root level of the message may optionally be documented 73 | on a `` element in the schema using the blockLength attribute. 74 | See section 4.5.3 above for message attributes. If not set in the 75 | schema, block length of the message root is the sum of its field 76 | lengths. Whether it is set in the schema or not, the block length is 77 | sent on the wire to consumers. 78 | 79 | Likewise, a repeating group has a blockLength attribute to tell how much 80 | space is reserved for group entries, and the value is sent on the wire. 81 | It is encoded in the schema as part of the NumInGroup field encoding. 82 | See section 3.4.8.2 above. 83 | 84 | ### Deprecated elements 85 | 86 | A message schema may document obsolete elements, such as messages, 87 | fields, and valid values of enumerations with deprecated attribute. 88 | Updated applications should not publish deprecated messages or values, 89 | but declarations may remain in the message schema during a staged 90 | migration to replacement message layouts. 91 | 92 | Wire format features for extension 93 | ---------------------------------- 94 | 95 | ### Message size 96 | 97 | It is assumed that a either message boundaries are delimited by a 98 | transport or session protocol header conveys the size of the whole 99 | message. See section 3.1 above. This enables a consumer to properly 100 | frame messages even when the message has been lengthened in a later 101 | version of the schema. 102 | 103 | ### Block size 104 | 105 | The length of the root level of the message is sent on the wire in the 106 | SBE message header. See section 3.2.2 above. Therefore, if new fields 107 | were appended in a later version of the schema, the consumer would still 108 | know how many octets to consume to find the next message element, such 109 | as repeating group or variable-length Data field. Without the current 110 | schema version, the consumer cannot interpret the new fields, but it 111 | does not break parsing of earlier fields. 112 | 113 | Likewise, block size of a repeating group is conveyed in the NumInGroup 114 | encoding. 115 | 116 | Comaptibility strategy 117 | ----------------------- 118 | *This suggested strategy is non-normative.* 119 | 120 | A message decoder compares the schema version in a received message header to the version that the decoder was built with. 121 | 122 | If the *received version is equal to the decoder's version*, then all fields known to the decoder may be parsed, and no further analysis is required. 123 | 124 | If the *received version is greater than the decoder's version* (that is, the producer's encoder is newer than the consumer's decoder), then all fields known to the decoder may be parsed but it will be unable to parse added fields. 125 | 126 | Also, an old decoder may encounter unexpected enumeration values. The application layer determines whether an unexpected value is a fatal error. Probably so for a required field since the business meaning is unknown, but it may choose to allow an unknown value of an optional field to pass through. For example, if OrdType value J="Market If Touched" is added to a schema, and the consumer does not recognize it, then the application returns an order rejection with reason "order type not supported", even if it does not know what "J" represents. Note that this is not strictly a versioning problem, however. This exception handling is indistinguishable from the case where "J" was never added to the enum but was simply sent in error. 127 | 128 | If the *received version is less than the decoder's version* (that is, the producer's encoder is older than the consumer's decoder), then only the fields of the older version may be parsed. This information is available through metadata as "sinceVersion" attribute of a field. If sinceVersion is greater than received schema version, then the field is not available. How a decoder signals an application that a field is unavailable is an implementation detail. One strategy is for an application to provide a default value for unavailable fields. 129 | 130 | Message schema extension example 131 | -------------------------------- 132 | 133 | Initial version of a message schema 134 | 135 | ```xml 136 | 137 | 138 | 139 | 140 | 141 | 142 | 143 | 144 | 145 | 146 | ``` 147 | 148 | Second version - a new message is added 149 | 150 | ```xml 151 | 153 | 154 | 155 | 156 | 158 | 159 | 160 | 161 | 162 | 163 | 164 | 165 | 167 | 168 | 169 | 170 | ``` 171 | 172 | Third version - a field is added 173 | 174 | ```xml 175 | 177 | 178 | 179 | 180 | 182 | 184 | 185 | 186 | 187 | 188 | 190 | 191 | 192 | 194 | 195 | 196 | 197 | ``` 198 | -------------------------------------------------------------------------------- /v1-0-RC4/doc/06UsageGuidelines.md: -------------------------------------------------------------------------------- 1 | Usage Guidelines 2 | ================ 3 | 4 | Identifier encodings 5 | ------------------------------------------------------------------------------------------------------------------- 6 | 7 | FIX specifies request and entity identifiers as String type. Common 8 | practice is to specify an identifier field as fixed-length character of 9 | a certain size. 10 | 11 | Optionally, a message schema may restrict such identifiers to numeric 12 | encodings. 13 | 14 | Example of an identifier field with character encoding 15 | 16 | ```xml 17 | 18 | 19 | 21 | ``` 22 | 23 | Example of an identifier field with numeric encoding 24 | 25 | ```xml 26 | 27 | 28 | 30 | ``` 31 | -------------------------------------------------------------------------------- /v1-0-RC4/doc/08ReleaseNotes.md: -------------------------------------------------------------------------------- 1 | Release Notes 2 | ============= 3 | Release Candidate 4 4 | ------------------- 5 | 6 | These issues were resolved and accepted for Release Candidate 4. See issues and pull requests 7 | in GitHub for details and changes. 8 | 9 | | Issue | Description | Section | 10 | |------:|----------------------------------------------------------------|---------| 11 | | 2 | Schema extension is vague in terms of what compatibility means | 5 12 | | 3 | Extensibility of the Template ID | 5 13 | | 6 | Limiting maximum occurences of repeating group | 3 14 | | 8 | blockLength for repeating groups of variable length | 3 15 | | 11 | Offsets within composite types | 4 16 | | 12 | Composites reusing other types | 4 17 | 18 | Release Candidate 3 19 | ------------------- 20 | 21 | This is a summary of document changes to Release Candidate 3 from RC2. 22 | Changes in this release were intended only as clarifications or to add 23 | capabilities. Message schemas that conformed to the RC2 specification 24 | should still conform to the RC3 wire format. 25 | 26 | **Section 1** 27 | 28 | References section expanded. 29 | 30 | **Section 2** 31 | 32 | - Statement added that non-FIX data types should not carry a 33 | semanticType attribute in a message schema. 34 | 35 | - String encoding section split into two sections for strings (text 36 | fields) and data (non-character data) to clarify the distinction. 37 | Both text and non-text can be either fixed-length `` or 38 | variable-length ``. 39 | 40 | - Timestamp encoding enhanced to allow time unit to either be 41 | specified as a constant in a message schema or to be serialized on 42 | the wire. 43 | 44 | **Section 3** 45 | 46 | Message structure is enhanced to allow variable-length `` elements 47 | within a repeating group entry. 48 | 49 | **Section 4** 50 | 51 | Message schema XSD updated to support `` in repeating groups and 52 | for various other refinements 53 | 54 | **Section 5** 55 | 56 | - Statements added to say whole repeating groups or variable data may 57 | be added to a message without breaking compatibility so long as the 58 | added elements are at the end of a message. 59 | 60 | - Added deprecated schema attribute to mark obsolete elements. 61 | 62 | **Section 6** 63 | 64 | No change 65 | 66 | **Section 7** 67 | 68 | Examples updated to use Simple Open Framing Header. 69 | 70 | **Section 8** 71 | 72 | Release notes added. 73 | -------------------------------------------------------------------------------- /v1-0-RC4/doc/media/image1.jpeg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fix-simple-binary-encoding/3dca4cee4e9afb2a1dee624f2bb68f8bc7525e25/v1-0-RC4/doc/media/image1.jpeg -------------------------------------------------------------------------------- /v1-0-RC4/doc/publication/Simple-Binary-Encoding-Release-Candidate-4.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fix-simple-binary-encoding/3dca4cee4e9afb2a1dee624f2bb68f8bc7525e25/v1-0-RC4/doc/publication/Simple-Binary-Encoding-Release-Candidate-4.pdf -------------------------------------------------------------------------------- /v1-0-RC4/resources/Examples.xml: -------------------------------------------------------------------------------- 1 | 2 | 7 | 8 | 9 | 10 | 12 | 13 | 15 | 16 | 17 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | -3 39 | 40 | 41 | 42 | 43 | 0 44 | 45 | 46 | 0 47 | 1 48 | 2 49 | 4 50 | 6 51 | 52 | 53 | 0 54 | 3 55 | 4 56 | 5 57 | 6 58 | 8 59 | A 60 | F 61 | 62 | 63 | 0 64 | 1 65 | 2 66 | 3 67 | 4 68 | 6 69 | 8 70 | A 71 | E 72 | 73 | 74 | 1 75 | 2 76 | 3 77 | 4 78 | 79 | 80 | 1 81 | 2 82 | 83 | 84 | 86 | 88 | 90 | 91 | 92 | 94 | 96 | 98 | 100 | 102 | 104 | 106 | 108 | 110 | 112 | 114 | 115 | 117 | 119 | 120 | 121 | 123 | 125 | 127 | 129 | 131 | 133 | 135 | 137 | 139 | 141 | 142 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/01Introduction.md: -------------------------------------------------------------------------------- 1 | # Scope 2 | 3 | This document provides the normative specification of Simple Binary Encoding (SBE), which is one of the possible syntaxes for FIX messages, but not limited to FIX messages. The scope comprises the encoding (wire format) and the message schema for SBE. 4 | 5 | # Normative references 6 | 7 | The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. 8 | 9 | --- IETF RFC 2119 -- *Key words for use in RFCs to Indicate Requirement Levels* March 1997 10 | 11 | # Terms and definitions 12 | 13 | For the purposes of this document, the terms and definitions given in ISO/IEC 11404 and the following apply. 14 | 15 | ISO and IEC maintain terminological databases for use in standardization at the following addresses: 16 | 17 | —-- ISO Online browsing platform: available at [https://www.iso.org/obp](https://www.iso.org/obp) 18 | 19 | —-- IEC Electropedia: available at [http://www.electropedia.org/](http://www.electropedia.org/) 20 | 21 | 22 | ## datatype 23 | field type with its associated encoding attributes 24 | 25 | Note 1 to entry: Includes backing primitive types and valid values or range. Some types 26 | have additional attributes, e.g. epoch of a date. 27 | 28 | ## encoding 29 | message format for interchange 30 | 31 | Note 1 to entry: The term is commonly used 32 | to mean the conversion of one data format to another, such as text to 33 | binary. However, SBE strives to use native binary 34 | datatypes in order to make conversion unnecessary, or at least trivial. 35 | 36 | Note 2 to entry: Encoding also refers to the act of formatting a message, as opposed to decoding. 37 | 38 | ## field 39 | unit of data contained by a message 40 | 41 | ## message schema 42 | metadata that specifies messages and their data types and identifiers 43 | 44 | Note 1 to entry: Message schemas may be disseminated out of band. 45 | 46 | Note 2 to entry: For SBE, message schemas are expressed as an XML 47 | document that conforms to an XML schema that is published as part of this standard. 48 | 49 | ## message template 50 | metadata that specifies the fields that belong to one particular message type 51 | 52 | Note 1 to entry: A message template is contained by a 53 | message schema. 54 | 55 | ## session protocol 56 | protocol concerned with the reliable delivery of messages over a transport. 57 | 58 | Note 1 to entry: FIX makes a distinction between 59 | session protocol and the encoding of a message payload, as described by 60 | this document. See the [specifications section](https://www.fixtrading.org/standards/) of the FIX Protocol web site 61 | for supported session protocols and encodings. 62 | 63 | ## XML schema 64 | defines the elements and attributes that may appear in an XML document. 65 | 66 | Note 1 to entry: The SBE message schema is defined in W3C (XSD) schema 67 | language since it is the most widely adopted format for XML schemas. 68 | 69 | ## Specification terms 70 | These key words in this document are to be interpreted as described in IETF RFC 2119. 71 | 72 | # Objectives 73 | 74 | ## General 75 | 76 | SBE was designed to meet the needs of high performance trading systems, but it may also be applicable to other applications with similar performance characteristics. It is optimized for low latency of encoding and decoding while 77 | keeping bandwidth utilization reasonably small. For compatibility, it is intended to represent all FIX semantics. 78 | 79 | This encoding specification describes the wire protocol for messages. 80 | Thus, it provides a standard for interoperability between communicating 81 | parties. Users are free to implement the standard in a way that best 82 | suits their needs. 83 | 84 | The encoding standard is complementary to other FIX standards for 85 | session protocol and application level behavior. 86 | 87 | ## Binary type system 88 | 89 | In order to support traditional FIX semantics, all the documented field 90 | types are supported. However, instead of printable character 91 | representations of tag-value encoding, the type system binds to native 92 | binary datatypes, and defines derived types as needed. 93 | 94 | The binary type system has been enhanced in these ways: 95 | 96 | - Provides a means to specify precision of decimal numbers and 97 | timestamps, as well as valid ranges of numbers. 98 | 99 | - Differentiates fixed-length character arrays from variable-length 100 | strings. Allows a way to specify the minimum and maximum length of 101 | strings that an application can accept. 102 | 103 | - Provides a consistent system of enumerations, Boolean switches and 104 | multiple-choice fields. 105 | 106 | ## Design principles 107 | 108 | The message design strives for direct data access without complex 109 | transformations or conditional logic. This is achieved by: 110 | 111 | - Usage of native binary datatypes and simple types derived from 112 | native binaries, such as prices and timestamps. 113 | 114 | - Preference for fixed positions and fixed length fields, supporting 115 | direct access to data and avoiding the need for management of heaps 116 | of variable-length elements which must be sequentially processed. 117 | 118 | ## Message schema 119 | 120 | This standard describes how fields are encoded and the general structure 121 | of messages. The content of a message type is specified by a message 122 | schema. A message schema tells which fields belong to a message and 123 | their location within a message. Additionally, the metadata describes 124 | valid value ranges and information that need not be sent on the wire, 125 | such as constant values. 126 | 127 | Message schemas may be based on standard FIX message specifications or 128 | may be customized as needed by agreement between counterparties. 129 | 130 | ## Documentation 131 | 132 | ### General 133 | 134 | This document explains: 135 | 136 | - The binary type system for field encoding 137 | 138 | - Message structure, including field arrangement, repeating groups, 139 | and relationship to a message header that may be provided by a 140 | session protocol. 141 | 142 | - The SBE message schema. 143 | 144 | ### Document format 145 | 146 | In this document, these formats are used for technical specifications 147 | and data examples. 148 | 149 | This is a sample encoding specification 150 | 151 | ```xml 152 | 153 | ``` 154 | 155 | This is sample data as it would be transmitted on the wire 156 | 157 | `10270000` 158 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/05SchemaExtensionMechanism.md: -------------------------------------------------------------------------------- 1 | # Schema Extension Mechanism 2 | 3 | ## Objective 4 | 5 | ### General 6 | 7 | It is not always practical to update all message publishers and 8 | consumers simultaneously. Within certain constraints, message schemas 9 | and wire formats can be extended in a controlled way. Consumers using an 10 | older version of a schema should be compatible if interpretation of 11 | added fields or messages is not required for business processing. 12 | 13 | This specification only details compatibility at the presentation layer. It does not relieve application developers of any responsibility for carefully planning a migration strategy and for handling exceptions at the application layer. 14 | 15 | ### Constraints 16 | 17 | Compatibility is only ensured under these conditions: 18 | 19 | - Fields may be added to either the root of a message or to a 20 | repeating group, but in each case, they must be appended to end of a 21 | block. 22 | 23 | - Existing fields cannot change data type or move within a message. 24 | 25 | - A repeating group may be added after existing groups at the root level or nested within another repeating group. 26 | 27 | - A variable-length data field may be added after existing variable-length data at the root level or within a repeating group. 28 | 29 | - Message header encoding cannot change. 30 | 31 | - In general, metadata changes such as name or description corrections do not break compatibility so long as 32 | wire format does not change. 33 | 34 | Changes that break those constraints require consumers to update to the 35 | current schema used by publishers. An message template that has changed in an incompatible way must be assinged a new template "id" attribute. 36 | 37 | ## Message schema features for extension 38 | 39 | ### Schema version 40 | 41 | The `` root element contains a version number attribute. 42 | By default, version is zero, the initial version of a message schema. 43 | Each time a message schema is changed, the version number is 44 | incremented. 45 | 46 | Version applies to the schema as a whole, not to individual elements. 47 | Version is sent in the message header so the consumer can determine 48 | which version of the message schema was used to encode the message. 49 | 50 | See section [*Message schema attributes*](#messageschema-attributes) for the specification. 51 | 52 | ### Since version 53 | 54 | When a new field, enumeration value, group or message is added to a message schema, the 55 | extension may be documented by adding a sinceVersion attribute to the 56 | element. The sinceVersion attribute tells in which schema version the 57 | element was added. This attribute remains the same for that element for 58 | the lifetime of the schema. This attribute is for documentation purposes 59 | only, it is not sent on the wire. 60 | 61 | Over time, multiple extensions may be added to a message schema. New 62 | fields must be appended following earlier extensions. By documenting 63 | when each element was added, it possible to verify that extensions were 64 | appended in proper order. 65 | 66 | ### Block length 67 | 68 | The length of the root level of the message may optionally be documented 69 | on a `` element in the schema using the blockLength attribute. 70 | See section [*Message element attributes*](#message-element-attributes) for details. If not set in the 71 | schema, block length of the message root is the sum of its field 72 | lengths. Whether it is set in the schema or not, the block length is 73 | sent on the wire to consumers. 74 | 75 | Likewise, a repeating group has a blockLength attribute to tell how much 76 | space is reserved for group entries, and the value is sent on the wire. 77 | It is encoded in the schema as part of the NumInGroup field encoding. 78 | See section [*Encoding of repeating group dimensions*](#encoding-of-repeating-group-dimensions) for details. 79 | 80 | ### Deprecated elements 81 | 82 | A message schema may document obsolete elements, such as messages, 83 | fields, and valid values of enumerations with deprecated attribute. 84 | Updated applications should not publish deprecated messages or values, 85 | but declarations may remain in the message schema during a staged 86 | migration to replacement message layouts. 87 | 88 | ## Wire format features for extension 89 | 90 | ### Block size 91 | 92 | The length of the root level of the message is sent on the wire in the 93 | SBE message header. See section [*Root block length*](#root-block-length) for details. Therefore, if new fields 94 | were appended in a later version of the schema, the consumer would still 95 | know how many octets to consume to find the next message element, such 96 | as repeating group or variable-length Data field. Without the current 97 | schema version, the consumer cannot interpret the new fields, but it 98 | does not break parsing of earlier fields. 99 | 100 | Likewise, block size of a repeating group is conveyed in the NumInGroup 101 | encoding. 102 | 103 | ### Number of repeating groups and variable data 104 | 105 | Message headers and repeating group dimensions carry a count of the number of repeating groups and a count of variable-length data fields on the wire. This supports a walk by a decoder of all the elements of a message, even when the decoder was built with an older version of a schema. As for added fixed-length fields, new repeating groups cannot be interpreted by the decoder, but it still can process the ones it knows, and it can correctly reach the end of a message. 106 | 107 | ## Compatibility strategy 108 | 109 | *This suggested strategy is non-normative.* 110 | 111 | A message decoder compares the schema version in a received message header to the version that the decoder was built with. 112 | 113 | If the *received version is equal to the decoder's version*, then all fields known to the decoder may be parsed, and no further analysis is required. 114 | 115 | If the *received version is greater than the decoder's version* (that is, the producer's encoder is newer than the consumer's decoder), then all fields known to the decoder may be parsed but it will be unable to parse added fields. 116 | 117 | Also, an old decoder may encounter unexpected enumeration values. The application layer determines whether an unexpected value is a fatal error. Probably so for a required field since the business meaning is unknown, but it may choose to allow an unknown value of an optional field to pass through. For example, if OrdType(40)=J (Market If Touched (MIT)) is added to a schema, and the consumer does not recognize it, then the application returns an order rejection with reason "order type not supported", even if it does not know what "J" represents. Note that this is not strictly a versioning problem, however. This exception handling is indistinguishable from the case where "J" was never added to the enum but was simply sent in error. 118 | 119 | If the *received version is less than the decoder's version* (that is, the producer's encoder is older than the consumer's decoder), then only the fields of the older version may be parsed. This information is available through metadata as sinceVersion attribute of a field. If sinceVersion is greater than received schema version, then the field is not available. How a decoder signals an application that a field is unavailable is an implementation detail. One strategy is for an application to provide a default value for unavailable fields. 120 | 121 | ## Message schema extension example 122 | 123 | ### Initial version of a message schema 124 | 125 | ```xml 126 | 127 | 128 | 129 | 130 | 131 | 132 | 133 | 134 | 135 | 136 | ``` 137 | 138 | ### Second version - a new message is added 139 | 140 | ```xml 141 | 142 | 143 | 144 | 145 | 146 | 147 | 148 | 149 | 150 | 151 | 152 | 153 | 154 | 155 | 156 | 157 | ``` 158 | 159 | ### Third version - a field is added 160 | 161 | ```xml 162 | 163 | 164 | 165 | 166 | 167 | 168 | 169 | 170 | 171 | 172 | 173 | 174 | 175 | 176 | 177 | 178 | 179 | ``` 180 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/06UsageGuidelines.md: -------------------------------------------------------------------------------- 1 | # Usage Guidelines 2 | 3 | ## Identifier encodings 4 | 5 | FIX specifies request and entity identifiers as String type. Common 6 | practice is to specify an identifier field as fixed-length character of 7 | a certain size. 8 | 9 | Optionally, a message schema may restrict such identifiers to numeric 10 | encodings. 11 | \ 12 | **Example of an identifier field with character encoding** 13 | 14 | ```xml 15 | 16 | 17 | 18 | ``` 19 | \ 20 | **Example of an identifier field with numeric encoding** 21 | 22 | ```xml 23 | 24 | 25 | 26 | ``` 27 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/FIXDisclaimerTechStd.md: -------------------------------------------------------------------------------- 1 | ::: {custom-style=Disclaimer} 2 | DISCLAIMER 3 | ::: 4 | 5 | THE INFORMATION CONTAINED HEREIN AND THE FINANCIAL INFORMATION EXCHANGE PROTOCOL (COLLECTIVELY, THE "FIX PROTOCOL") ARE PROVIDED "AS IS" AND NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL MAKES ANY REPRESENTATION OR WARRANTY, EXPRESS OR IMPLIED, AS TO THE FIX PROTOCOL (OR THE RESULTS TO BE OBTAINED BY THE USE THEREOF) OR ANY OTHER MATTER AND EACH SUCH PERSON AND ENTITY SPECIFICALLY DISCLAIMS ANY WARRANTY OF ORIGINALITY, ACCURACY, COMPLETENESS, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SUCH PERSONS AND ENTITIES DO NOT WARRANT THAT THE FIX PROTOCOL WILL CONFORM TO ANY DESCRIPTION THEREOF OR BE FREE OF ERRORS. THE ENTIRE RISK OF ANY USE OF THE FIX PROTOCOL IS ASSUMED BY THE USER. 6 | 7 | NO PERSON OR ENTITY ASSOCIATED WITH THE FIX PROTOCOL SHALL HAVE ANY LIABILITY FOR DAMAGES OF ANY KIND ARISING IN ANY MANNER OUT OF OR IN CONNECTION WITH ANY USER'S USE OF (OR ANY INABILITY TO USE) THE FIX PROTOCOL, WHETHER DIRECT, INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL (INCLUDING, WITHOUT LIMITATION, LOSS OF DATA, LOSS OF USE, CLAIMS OF THIRD PARTIES OR LOST PROFITS OR REVENUES OR OTHER ECONOMIC LOSS), WHETHER IN TORT (INCLUDING NEGLIGENCE AND STRICT LIABILITY), CONTRACT OR OTHERWISE, WHETHER OR NOT ANY SUCH PERSON OR ENTITY HAS BEEN ADVISED OF, OR OTHERWISE MIGHT HAVE ANTICIPATED THE POSSIBILITY OF, SUCH DAMAGES. 8 | 9 | **DRAFT OR NOT RATIFIED PROPOSALS** (REFER TO PROPOSAL STATUS AND/OR SUBMISSION STATUS ON COVER PAGE) ARE PROVIDED "AS IS" TO INTERESTED 10 | PARTIES FOR DISCUSSION ONLY. PARTIES THAT CHOOSE TO IMPLEMENT THIS DRAFT PROPOSAL DO SO AT THEIR OWN RISK. IT IS A DRAFT DOCUMENT AND MAY BE 11 | UPDATED, REPLACED, OR MADE OBSOLETE BY OTHER DOCUMENTS AT ANY TIME. THE FIX GLOBAL TECHNICAL COMMITTEE WILL NOT ALLOW EARLY IMPLEMENTATION TO 12 | CONSTRAIN ITS ABILITY TO MAKE CHANGES TO THIS SPECIFICATION PRIOR TO FINAL RELEASE. IT IS INAPPROPRIATE TO USE FIX WORKING DRAFTS AS 13 | REFERENCE MATERIAL OR TO CITE THEM AS OTHER THAN “WORKS IN PROGRESS”. THE FIX GLOBAL TECHNICAL COMMITTEE WILL ISSUE, UPON COMPLETION OF REVIEW 14 | AND RATIFICATION, AN OFFICIAL STATUS ("APPROVED") OF/FOR THE PROPOSAL AND A RELEASE NUMBER. 15 | 16 | No proprietary or ownership interest of any kind is granted with respect to the FIX Protocol (or any rights therein), except as expressly set out in FIX Protocol Limited's Copyright and Acceptable Use Policy. 17 | 18 | © Copyright 2013-2020 FIX Protocol Limited, all rights reserved 19 | 20 | \ 21 | 22 | ![](https://i.creativecommons.org/l/by-nd/4.0/88x31.png) 23 | 24 | FIX Technical Standard Specifications by [FIX Protocol Ltd.](https://www.fixtradingcommunity.org/) are licensed under a [Creative Commons Attribution-NoDerivatives 4.0 International License](http://creativecommons.org/licenses/by-nd/4.0/). Based on a work at [https://github.com/FIXTradingCommunity/](https://github.com/FIXTradingCommunity/). 25 | 26 | 27 | 1. 28 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/FIX_TechStd_Style_MASTER.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fix-simple-binary-encoding/3dca4cee4e9afb2a1dee624f2bb68f8bc7525e25/v1-0-STANDARD/doc/FIX_TechStd_Style_MASTER.docx -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/ISOBiblio.md: -------------------------------------------------------------------------------- 1 | ::: {custom-style="Annex"} 2 | **Bibliography** 3 | ::: 4 | 5 | [1] Simple Open Framing Header (SOFH) Draft Standard v1.0, *Message framing standard for FIX messages* [https://www.fixtrading.org/standards/fix-sofh/](https://www.fixtrading.org/standards/fix-sofh/) 6 | 7 | [2] FIX Latest, *Normative specification of the FIX Protocol* [https://www.fixtrading.org/online-specification/](https://www.fixtrading.org/online-specification/) 8 | 9 | [3] IEEE 754, *IEEE Standard for Binary Floating-Point Arithmetic* [https://ieeexplore.ieee.org/document/8766229](https://ieeexplore.ieee.org/document/8766229) 10 | 11 | [4] ISO 639-1, *Codes for the representation of names of languages — Part 1: Alpha-2 code* [https://www.iso.org/standard/22109.html](https://www.iso.org/standard/22109.html) 12 | 13 | [5] ISO 3166-1, *Codes for the representation of names of countries and their subdivisions — Part 1: Country codes* [https://www.iso.org/standard/63545.html](https://www.iso.org/standard/63545.html) 14 | 15 | [6] ISO 4217, *Codes for the representation of currencies and funds* [https://www.iso.org/standard/64758.html](https://www.iso.org/standard/64758.html) 16 | 17 | [7] ISO 8601, *Data elements and interchange formats - Information interchange — Representation of dates and times* [https://www.iso.org/standard/40874.html](https://www.iso.org/standard/40874.html) 18 | 19 | [8] ISO 10383, *Securities and related financial instruments — Codes for exchanges and market identification (MIC)* [https://www.iso.org/standard/61067.html](https://www.iso.org/standard/61067.html) 20 | 21 | [9] ISO/IEC 11404, *Information technology — General-Purpose Datatypes (GPD)* [https://www.iso.org/standard/39479.html](https://www.iso.org/standard/39479.html) 22 | 23 | [10] W3C XML Schema, *XML 1.1 schema standards* [http://www.w3.org/XML/Schema.html#dev](http://www.w3.org/XML/Schema.html#dev) 24 | 25 | [11] IETF RFC 2119, *Keywords for use in RFCs to Indicate Requirement Levels March 1997* [https://datatracker.ietf.org/doc/html/rfc2119](https://datatracker.ietf.org/doc/html/rfc2119) 26 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/ISOCopyright.md: -------------------------------------------------------------------------------- 1 | ::: {custom-style="TextBox"} 2 | © ISO 2022\ 3 | \ 4 | All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.\ 5 | \ 6 |         ISO copyright office\ 7 |         CP 401 • Ch. de Blandonnet 8\ 8 |         CH-1214 Vernier, Geneva\ 9 |         Phone: +41 22 749 01 11\ 10 |         Fax: +41 22 749 09 47\ 11 |         Email: copyright@iso.org\ 12 |         Website: www.iso.org\ 13 | \ 14 | Published in Switzerland 15 | ::: 16 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/ISOForeword.md: -------------------------------------------------------------------------------- 1 | ::: {custom-style="NewPageWithTOC"} 2 | **Foreword** 3 | ::: 4 | 5 | ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. 6 | 7 | The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see [www.iso.org/directives](www.iso.org/directives)). 8 | 9 | Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see [www.iso.org/patents](www.iso.org/patents)). 10 | 11 | Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement. 12 | 13 | For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following URL: [www.iso.org/iso/foreword.html](www.iso.org/iso/foreword.html). 14 | 15 | This document was prepared by Technical Committee ISO/TC 68, *Financial Services*, Subcommittee SC 9, *Information Exchange* 16 | 17 | A list of all parts in the ISO ##### series can be found on the ISO website. 18 | 19 | Any feedback or questions on this document should be directed to the user’s national standards body. A complete listing of these bodies can be found at [www.iso.org/members.html](www.iso.org/members.html). 20 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/ISOIntro.md: -------------------------------------------------------------------------------- 1 | ::: {custom-style="NewPageWithTOC"} 2 | Introduction 3 | ::: 4 | 5 | The Financial Information eXchange Simple Binary Encoding (SBE) targets high performance trading systems. It is optimized for low latency of encoding and decoding while keeping bandwidth utilization reasonably small. For compatibility, it is intended to represent all FIX semantics. SBE is primarily a fixed length wire format but also supports variable length fields and repeating groups with fixed length entries. The wire format does not contain any meta-data other than length information for variable elements. The meta-data is a message schema provided out-of-band as an XML Schema Definition (XSD) file. 6 | 7 | ::: {custom-style="NewPage"} 8 | **Financial Services -- Financial Information eXchange -- Simple Binary Encoding** 9 | ::: 10 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/ISO_TechStd_Style_MASTER.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fix-simple-binary-encoding/3dca4cee4e9afb2a1dee624f2bb68f8bc7525e25/v1-0-STANDARD/doc/ISO_TechStd_Style_MASTER.docx -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/JTC1Biblio.md: -------------------------------------------------------------------------------- 1 | ::: {custom-style="Annex"} 2 | **Bibliography** 3 | ::: 4 | 5 | [1] Simple Open Framing Header (SOFH) Draft Standard v1.0, *Message framing standard for FIX messages* [https://www.fixtrading.org/standards/fix-sofh/](https://www.fixtrading.org/standards/fix-sofh/) 6 | 7 | [2] FIX Latest, *Normative specification of the FIX Protocol* [https://www.fixtrading.org/online-specification/](https://www.fixtrading.org/online-specification/) 8 | 9 | [3] IEEE 754, *IEEE Standard for Binary Floating-Point Arithmetic* [https://ieeexplore.ieee.org/document/8766229](https://ieeexplore.ieee.org/document/8766229) 10 | 11 | [4] ISO 639-1, *Codes for the representation of names of languages — Part 1: Alpha-2 code* [https://www.iso.org/standard/22109.html](https://www.iso.org/standard/22109.html) 12 | 13 | [5] ISO 3166-1, *Codes for the representation of names of countries and their subdivisions — Part 1: Country codes* [https://www.iso.org/standard/63545.html](https://www.iso.org/standard/63545.html) 14 | 15 | [6] ISO 4217, *Codes for the representation of currencies and funds* [https://www.iso.org/standard/64758.html](https://www.iso.org/standard/64758.html) 16 | 17 | [7] ISO 8601, *Data elements and interchange formats - Information interchange — Representation of dates and times* [https://www.iso.org/standard/40874.html](https://www.iso.org/standard/40874.html) 18 | 19 | [8] ISO 10383, *Securities and related financial instruments — Codes for exchanges and market identification (MIC)* [https://www.iso.org/standard/61067.html](https://www.iso.org/standard/61067.html) 20 | 21 | [9] ISO/IEC 11404, *Information technology — General-Purpose Datatypes (GPD)* [https://www.iso.org/standard/39479.html](https://www.iso.org/standard/39479.html) 22 | 23 | [10] W3C XML Schema, *XML 1.1 schema standards* [http://www.w3.org/XML/Schema.html#dev](http://www.w3.org/XML/Schema.html#dev) 24 | 25 | [11] IETF RFC 2119, *Keywords for use in RFCs to Indicate Requirement Levels March 1997* [https://datatracker.ietf.org/doc/html/rfc2119](https://datatracker.ietf.org/doc/html/rfc2119) 26 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/JTC1Copyright.md: -------------------------------------------------------------------------------- 1 | ::: {custom-style="TextBox"} 2 | **COPYRIGHT PROTECTED DOCUMENT**\ 3 | \ 4 | © ISO/IEC 2024\ 5 | \ 6 | All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester.\ 7 | \ 8 | **ISO copyright office** **IEC Secretariat**\ 9 | CP 401 • Ch. de Blandonnet 8 3, rue de Varembé\ 10 | CH-1214 Vernier, Geneva CH-1211 Geneva 20\ 11 | Phone: +41 22 749 01 11 Phone: +41 22 919 02 11\ 12 | Fax: +41 22 749 09 47 Fax: +41 22 919 03 00\ 13 | Email: copyright@iso.org Email: info@iec.ch\ 14 | Website: [www.iso.org](http://www.iso.org) Website: [www.iec.ch](http://www.iec.ch)\ 15 | \ 16 | Published in Switzerland 17 | ::: 18 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/JTC1Foreword.md: -------------------------------------------------------------------------------- 1 | ::: {custom-style="NewPageWithTOC"} 2 | **Foreword** 3 | ::: 4 | 5 | ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. 6 | 7 | The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see [www.iso.org/directives](www.iso.org/directives)). 8 | 9 | Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see [www.iso.org/patents](www.iso.org/patents)) or the IEC list of patent declarations received (see [http://patents.iec.ch](http://patents.iec.ch)). 10 | 11 | Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement. 12 | 13 | For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see [www.iso.org/iso/foreword.html](www.iso.org/iso/foreword.html). 14 | 15 | This document was prepared by the Joint Development Foundation (as OpenChain Specification) and drafted in accordance with its editorial rules. It was adopted, under the JTC 1 PAS procedure, by Joint Technical Committee ISO/IEC JTC 1, *Information technology*. 16 | 17 | Any feedback or questions on this document should be directed to the user’s national standards body. A complete listing of these bodies can be found at [www.iso.org/members.html](www.iso.org/members.html). 18 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/JTC1Intro.md: -------------------------------------------------------------------------------- 1 | ::: {custom-style="NewPageWithTOC"} 2 | Introduction 3 | ::: 4 | 5 | The Financial Information eXchange Simple Binary Encoding (SBE) targets high performance trading systems. It is optimized for low latency of encoding and decoding while keeping bandwidth utilization reasonably small. For compatibility, it is intended to represent all FIX semantics. SBE is primarily a fixed length wire format but also supports variable length fields and repeating groups with fixed length entries. The wire format does not contain any meta-data other than length information for variable elements. The meta-data is a message schema provided out-of-band as an XML Schema Definition (XSD) file. 6 | 7 | ::: {custom-style="NewPage"} 8 | **Financial Services -- Financial Information eXchange -- Simple Binary Encoding** 9 | ::: 10 | -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/JTC1_TechStd_Style_MASTER.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/FIXTradingCommunity/fix-simple-binary-encoding/3dca4cee4e9afb2a1dee624f2bb68f8bc7525e25/v1-0-STANDARD/doc/JTC1_TechStd_Style_MASTER.docx -------------------------------------------------------------------------------- /v1-0-STANDARD/doc/SBE.cmd: -------------------------------------------------------------------------------- 1 | echo Compilation started... 2 | :: Script is expected to start running in the folder where it is located (together with the source files) 3 | set SOURCE=%CD% 4 | :: There is only one disclaimer and style docx file for all FIX Technical Standards and it is stored with the FIX Session Layer 5 | :: Repository has local copies with the specific names and dates of the standard 6 | set DISCLAIMER=FIXDisclaimerTechStd.md 7 | set STYLE=FIX_TechStd_Style_MASTER.docx 8 | set TARGET=%SOURCE%\target 9 | set YAML=%SOURCE%\SBE.yaml 10 | set FILES=01Introduction.md 02FieldEncoding.md 03MessageStructure.md 04MessageSchema.md 05SchemaExtensionMechanism.md 06UsageGuidelines.md 07Examples.md 11 | set WPFOLDER=\wp-content\uploads\2020\03\ 12 | 13 | :: Create FIX document version with disclaimer 14 | pandoc "%DISCLAIMER%" %FILES% -o "%TARGET%\docx\Simple_Binary_Encoding_V1.0_with_Errata.docx" --reference-doc="%STYLE%" --metadata-file="%YAML%" --toc --toc-depth=4 15 | echo SBE document version created for FIX 16 | 17 | :: Create ISO document version with copyright etc. 18 | set ISOYAML=%SOURCE%\SBE_ISO.yaml 19 | set ISOSTYLE=ISO_TechStd_Style_MASTER.docx 20 | set ISOCOPYRIGHT=ISOCopyright.md 21 | set ISOFOREWORD=ISOForeword.md 22 | set ISOINTRO=ISOIntro.md 23 | :: set ISOBIBLIO=ISOBiblio.md 24 | 25 | pandoc %ISOCOPYRIGHT% %ISOFOREWORD% %ISOINTRO% %FILES% -o "%TARGET%\docx\ISOSimple_Binary_Encoding.docx" --reference-doc=%ISOSTYLE% --metadata-file=%ISOYAML% --filter pandoc-plantuml --toc --toc-depth=3 26 | echo SBE document version created for ISO 27 | 28 | :: Create base online version without disclaimer 29 | :: pandoc $FILES -o "$TARGET/debug/SBEONLINE.html" -s --metadata-file="$YAML" --toc --toc-depth=2 30 | 31 | :: Remove title as it is redundant to page header 32 | :: sed -i '.bak1' '/

/d' "$TARGET/debug/SBEONLINE.html" 33 | 34 | :: Add header for table of contents 35 | :: sed -i '.bak2' '/