Imported from previous forum
Hello
We are currently working on a FIXML API for trade registration.
We choose FIXML over FIX to gain better readability on the cost of 70% (i think someone stated) bigger data chunks.
I was wondering, if anyone has concidered making a JSON equivalent to the FIXML? JSON is a readable standard just like XML and is widely used in tons of applications (e.g. JavaScript in browsers, data format in many document oriented databases).
I made an example of how a JSON equivalent to a FIXML might look:
FIXML:
JSON: (e.g. FIXON):
{
v: “4.4”,
ExecRep: {
SID=“AAB”,
TID="BBC"
Exec: [
{ id=“L1” },
{ id=“L2” }
]
}
}
The JSON version only uses 80% of the space of the FIXML version.
If FIXML uses 70% more than fix, my calculations show, that JSON would only be 36% more then FIX. This would give nearly the same effective memory usage as FIX and still keeping the data very human readable.
I look forward to hear your oppinions on this.
Thankyou in advance
/Stephan Ryer
Let’s do it! Great idea
But let’s not make some of the mistakes I made when we optimized FIXML.
Standard Bank performed an analysis of the issues that made fix to fixml transformation difficult.
We have other encoding efforts underway now (simple binary, asn.1, google protocol buffers) a JSON encoding spec makes a great deal of sense.
Can you lead this group if GTC approves?
Hello
We are currently working on a FIXML API for trade registration.
We choose FIXML over FIX to gain better readability on the cost of 70% (i think someone stated) bigger data chunks.I was wondering, if anyone has concidered making a JSON equivalent to the FIXML? JSON is a readable standard just like XML and is widely used in tons of applications (e.g. JavaScript in browsers, data format in many document oriented databases).
I made an example of how a JSON equivalent to a FIXML might look:
FIXML:
JSON: (e.g. FIXON):
{
v: “4.4”,
ExecRep: {
SID=“AAB”,
TID=“BBC”
Exec: [
{ id=“L1” },
{ id=“L2” }
]
}
}The JSON version only uses 80% of the space of the FIXML version.
If FIXML uses 70% more than fix, my calculations show, that JSON would only be 36% more then FIX. This would give nearly the same effective memory usage as FIX and still keeping the data very human readable.I look forward to hear your oppinions on this.
Thankyou in advance
/Stephan Ryer
I would love to. But what does it include to lead the group?
Things we must take into concern though:
- Should we do it JSON or BSON way. BSON supports native types as true/false, dates etc. while JSON only supports strings. To keep conversion from FIXML, I will suggest using JSON. The transformation should then be a trivial straight forward task for all FIXML messages.
- JSON Schemas. As there are fixml-schemas defining FIXML, we must also have JSON schemas for a formal description of the JSON format.
- What things would you like to be different from fixml? You mention you made some mistakes in the fixml implementation. I would rather inherit these mistakes, keeping JSON a true equivalent to FIXML and then fix mistakes in fixml and json at the same time on future releases. Keeping all conversion between encoding formats trivial may safe us some headeches, but this is a topic for discussion ofcourse.
I would like to hear more about the mistakes you mentioned.
Let’s do it! Great idea
But let’s not make some of the mistakes I made when we optimized FIXML.
Standard Bank performed an analysis of the issues that made fix to fixml transformation difficult.
We have other encoding efforts underway now (simple binary, asn.1, google protocol buffers) a JSON encoding spec makes a great deal of sense.
Can you lead this group if GTC approves?
Hello
We are currently working on a FIXML API for trade registration.
We choose FIXML over FIX to gain better readability on the cost of 70% (i think someone stated) bigger data chunks.I was wondering, if anyone has concidered making a JSON equivalent to the FIXML? JSON is a readable standard just like XML and is widely used in tons of applications (e.g. JavaScript in browsers, data format in many document oriented databases).
I made an example of how a JSON equivalent to a FIXML might look:
FIXML:
JSON: (e.g. FIXON):
{
v: “4.4”,
ExecRep: {
SID=“AAB”,
TID=“BBC”
Exec: [
{ id=“L1” },
{ id=“L2” }
]
}
}The JSON version only uses 80% of the space of the FIXML version.
If FIXML uses 70% more than fix, my calculations show, that JSON would only be 36% more then FIX. This would give nearly the same effective memory usage as FIX and still keeping the data very human readable.I look forward to hear your oppinions on this.
Thankyou in advance
/Stephan Ryer
-
Leading a working group. Be available to lead for weekly or twice monthly status calls. 3 to 5 hours per month. Help draft specification. For this case I would estimate 40 to 60 hours total. Participate in reviews, answer questions. 2 to 3 hours per month.
-
JSON v. BSON. I do not know the answer. Both? One or the other? Need more input. I know of markets using JSON now. BSON sounds interesting.
-
FIXML mistakes: Incomplete mappings (Data encoded fields, NumInGroup field identity primarily).
-
Interesting - your recommendation of keep a JSON/BSON mapping synchronized with FIXML so we have a trivial FIXML-JSON/BSON mapping, then improve FIX to FIXML/JSON/BSON transformation.
-
FPL would add a generator to produce the JSOB/BSON schema from the FIX Repository, similar to what is done for FIXML now. Other encoding groups: GPB and ASN.1 will have generators as well.
I would love to. But what does it include to lead the group?
Things we must take into concern though:
- Should we do it JSON or BSON way. BSON supports native types as true/false, dates etc. while JSON only supports strings. To keep conversion from FIXML, I will suggest using JSON. The transformation should then be a trivial straight forward task for all FIXML messages.
- JSON Schemas. As there are fixml-schemas defining FIXML, we must also have JSON schemas for a formal description of the JSON format.
- What things would you like to be different from fixml? You mention you made some mistakes in the fixml implementation. I would rather inherit these mistakes, keeping JSON a true equivalent to FIXML and then fix mistakes in fixml and json at the same time on future releases. Keeping all conversion between encoding formats trivial may safe us some headeches, but this is a topic for discussion ofcourse.
I would like to hear more about the mistakes you mentioned.
-
I would like to participate as a leader of the group.
-
No need for both IMO. They are almost equal. Having a MongoDB og CouchDB database for logging FIXON messages would be a straight forward task as they store their documents in JSON/BSON format, enabling intelligent querying without having to transform the data.
-
Sounds nice being able to transform XML Schemas to JSON Schemas.
All in all, the JSON implementation might almost be a 2-step, trivial conversion of the fixml specifications.
Regarding your initial enthusiasm of a new JSON format along with the already upcomming GPB and ASN.1 formats, leads me to the question: Why is there a need for all these formats? Won’t too many formats counter the idea of a common protocol with a common format?
Leading a working group. Be available to lead for weekly or twice monthly status calls. 3 to 5 hours per month. Help draft specification. For this case I would estimate 40 to 60 hours total. Participate in reviews, answer questions. 2 to 3 hours per month.
JSON v. BSON. I do not know the answer. Both? One or the other? Need more input. I know of markets using JSON now. BSON sounds interesting.
FIXML mistakes: Incomplete mappings (Data encoded fields, NumInGroup field identity primarily).
Interesting - your recommendation of keep a JSON/BSON mapping synchronized with FIXML so we have a trivial FIXML-JSON/BSON mapping, then improve FIX to FIXML/JSON/BSON transformation.
FPL would add a generator to produce the JSOB/BSON schema from the FIX Repository, similar to what is done for FIXML now. Other encoding groups: GPB and ASN.1 will have generators as well.
I would love to. But what does it include to lead the group?
Things we must take into concern though:
- Should we do it JSON or BSON way. BSON supports native types as true/false, dates etc. while JSON only supports strings. To keep conversion from FIXML, I will suggest using JSON. The transformation should then be a trivial straight forward task for all FIXML messages.
- JSON Schemas. As there are fixml-schemas defining FIXML, we must also have JSON schemas for a formal description of the JSON format.
- What things would you like to be different from fixml? You mention you made some mistakes in the fixml implementation. I would rather inherit these mistakes, keeping JSON a true equivalent to FIXML and then fix mistakes in fixml and json at the same time on future releases. Keeping all conversion between encoding formats trivial may safe us some headeches, but this is a topic for discussion ofcourse.
I would like to hear more about the mistakes you mentioned.
Good question regarding the impact of multiple encodings, I hear quite a bit of concerns on support for multiple encodings of the FIX Protocol.
A generally widely held view is that what is important is the business process level implemented via FIX application messages and the standardization at the semantic and business process /transaction levels. I think this view is the official view of the FIX Protocol community as represented by GSC and GTC leadership and participants.
Here is my personal views, and not necessarily the views of the wider FIX Community, on multiple encodings.
I see the ability to support the standard FIX business level (application level messaging) across a wide variety of horizontal information technology standards at the message encoding and session layer (middleware/messaging), such as but not limited to (ASN.1, Google Protocol Buffers, JSON/BSON encodings, AMQP, JMS messaging), and to an extent FIXML, as being important for compatibility / integration encodings that support seamless integration of FIX with enterprise applications and architectures of firms using FIX. Whether or not these encodings also develop “critical mass” or network economic benefits in actual inter-party communication, and the possible negative impact on network economic benefits of our standard encodings, that is really under the control of FIX adopters. These are not necessarily mutually exclusive - meaning that adoption of an alternative encoding or messaging layer by a community does not necessarily create a negative value to the existing standard FIX encoding / session layer.
For instance, a JSON/BSON integration that supports integration of FIX application messaging with internet / cloud based applications is not incompatible with the use of the same FIX application messaging over FIX.4.4 tag=value over FIX session level with counterparties or markets from within the same application.
Again my take is that the more easily FIX business level semantics can be integrated into the technology ecosystem, the better for all participants.
You have some good points. Regarding being able to handle FIX 4.4 tag=value over session layer when already supporting fixml for a specific messaging type:
As I read it, you say that a specific FIXML/JSON message is not incompatible with FIX 4.4 tag=value. I don’t follow you on this one, but maybe I just misunderstood. If I as a company support FIXML Execution Reports over MQ, I do not automatically support FIX 4.4 tag=value at all. In fact, I would rather never choose to support multiple formats for the same message type. The benefits (if any) of doing this does not outweight the cost of maintaining both APIs.
Or did I get you wrong on this one? 
Good question regarding the impact of multiple encodings, I hear quite a bit of concerns on support for multiple encodings of the FIX Protocol.
A generally widely held view is that what is important is the business process level implemented via FIX application messages and the standardization at the semantic and business process /transaction levels. I think this view is the official view of the FIX Protocol community as represented by GSC and GTC leadership and participants.
Here is my personal views, and not necessarily the views of the wider FIX Community, on multiple encodings.
I see the ability to support the standard FIX business level (application level messaging) across a wide variety of horizontal information technology standards at the message encoding and session layer (middleware/messaging), such as but not limited to (ASN.1, Google Protocol Buffers, JSON/BSON encodings, AMQP, JMS messaging), and to an extent FIXML, as being important for compatibility / integration encodings that support seamless integration of FIX with enterprise applications and architectures of firms using FIX. Whether or not these encodings also develop “critical mass” or network economic benefits in actual inter-party communication, and the possible negative impact on network economic benefits of our standard encodings, that is really under the control of FIX adopters. These are not necessarily mutually exclusive - meaning that adoption of an alternative encoding or messaging layer by a community does not necessarily create a negative value to the existing standard FIX encoding / session layer.
For instance, a JSON/BSON integration that supports integration of FIX application messaging with internet / cloud based applications is not incompatible with the use of the same FIX application messaging over FIX.4.4 tag=value over FIX session level with counterparties or markets from within the same application.
Again my take is that the more easily FIX business level semantics can be integrated into the technology ecosystem, the better for all participants.
Hi everyone,
Has there been any movement on developing “FIXON” (FIX in JSON) since this conversation last August?
Thanks,
-Mark
I would like to participate as a leader of the group.
No need for both IMO. They are almost equal. Having a MongoDB og CouchDB database for logging FIXON messages would be a straight forward task as they store their documents in JSON/BSON format, enabling intelligent querying without having to transform the data.
Sounds nice being able to transform XML Schemas to JSON Schemas.
All in all, the JSON implementation might almost be a 2-step, trivial conversion of the fixml specifications.
Regarding your initial enthusiasm of a new JSON format along with the already upcomming GPB and ASN.1 formats, leads me to the question: Why is there a need for all these formats? Won’t too many formats counter the idea of a common protocol with a common format?
Leading a working group. Be available to lead for weekly or twice monthly status calls. 3 to 5 hours per month. Help draft specification. For this case I would estimate 40 to 60 hours total. Participate in reviews, answer questions. 2 to 3 hours per month.
JSON v. BSON. I do not know the answer. Both? One or the other? Need more input. I know of markets using JSON now. BSON sounds interesting.
FIXML mistakes: Incomplete mappings (Data encoded fields, NumInGroup field identity primarily).
Interesting - your recommendation of keep a JSON/BSON mapping synchronized with FIXML so we have a trivial FIXML-JSON/BSON mapping, then improve FIX to FIXML/JSON/BSON transformation.
FPL would add a generator to produce the JSOB/BSON schema from the FIX Repository, similar to what is done for FIXML now. Other encoding groups: GPB and ASN.1 will have generators as well.
I would love to. But what does it include to lead the group?
Things we must take into concern though:
- Should we do it JSON or BSON way. BSON supports native types as true/false, dates etc. while JSON only supports strings. To keep conversion from FIXML, I will suggest using JSON. The transformation should then be a trivial straight forward task for all FIXML messages.
- JSON Schemas. As there are fixml-schemas defining FIXML, we must also have JSON schemas for a formal description of the JSON format.
- What things would you like to be different from fixml? You mention you made some mistakes in the fixml implementation. I would rather inherit these mistakes, keeping JSON a true equivalent to FIXML and then fix mistakes in fixml and json at the same time on future releases. Keeping all conversion between encoding formats trivial may safe us some headeches, but this is a topic for discussion ofcourse.
I would like to hear more about the mistakes you mentioned.
Hello,
One quick correction: JSON supports all the native types (null, Boolean, Number, String, Array, and Object). BSON is an extension of JSON that is serialized into binary and has extensions for additional types, such as Date.
Cheers.
I would love to. But what does it include to lead the group?
Things we must take into concern though:
- Should we do it JSON or BSON way. BSON supports native types as true/false, dates etc. while JSON only supports strings. To keep conversion from FIXML, I will suggest using JSON. The transformation should then be a trivial straight forward task for all FIXML messages.
- JSON Schemas. As there are fixml-schemas defining FIXML, we must also have JSON schemas for a formal description of the JSON format.
- What things would you like to be different from fixml? You mention you made some mistakes in the fixml implementation. I would rather inherit these mistakes, keeping JSON a true equivalent to FIXML and then fix mistakes in fixml and json at the same time on future releases. Keeping all conversion between encoding formats trivial may safe us some headeches, but this is a topic for discussion ofcourse.
I would like to hear more about the mistakes you mentioned.
Let’s do it! Great idea
But let’s not make some of the mistakes I made when we optimized FIXML.
Standard Bank performed an analysis of the issues that made fix to fixml transformation difficult.
We have other encoding efforts underway now (simple binary, asn.1, google protocol buffers) a JSON encoding spec makes a great deal of sense.
Can you lead this group if GTC approves?
Hello
We are currently working on a FIXML API for trade registration.
We choose FIXML over FIX to gain better readability on the cost of 70% (i think someone stated) bigger data chunks.I was wondering, if anyone has concidered making a JSON equivalent to the FIXML? JSON is a readable standard just like XML and is widely used in tons of applications (e.g. JavaScript in browsers, data format in many document oriented databases).
I made an example of how a JSON equivalent to a FIXML might look:
FIXML:
JSON: (e.g. FIXON):
{
v: “4.4”,
ExecRep: {
SID=“AAB”,
TID=“BBC”
Exec: [
{ id=“L1” },
{ id=“L2” }
]
}
}The JSON version only uses 80% of the space of the FIXML version.
If FIXML uses 70% more than fix, my calculations show, that JSON would only be 36% more then FIX. This would give nearly the same effective memory usage as FIX and still keeping the data very human readable.I look forward to hear your oppinions on this.
Thankyou in advance
/Stephan Ryer
Hi Sam
You are totally right. Tyhankyou for pointing that out!
Hello,
One quick correction: JSON supports all the native types (null, Boolean, Number, String, Array, and Object). BSON is an extension of JSON that is serialized into binary and has extensions for additional types, such as Date.
Cheers.
I would love to. But what does it include to lead the group?
Things we must take into concern though:
- Should we do it JSON or BSON way. BSON supports native types as true/false, dates etc. while JSON only supports strings. To keep conversion from FIXML, I will suggest using JSON. The transformation should then be a trivial straight forward task for all FIXML messages.
- JSON Schemas. As there are fixml-schemas defining FIXML, we must also have JSON schemas for a formal description of the JSON format.
- What things would you like to be different from fixml? You mention you made some mistakes in the fixml implementation. I would rather inherit these mistakes, keeping JSON a true equivalent to FIXML and then fix mistakes in fixml and json at the same time on future releases. Keeping all conversion between encoding formats trivial may safe us some headeches, but this is a topic for discussion ofcourse.
I would like to hear more about the mistakes you mentioned.
Let’s do it! Great idea
But let’s not make some of the mistakes I made when we optimized FIXML.
Standard Bank performed an analysis of the issues that made fix to fixml transformation difficult.
We have other encoding efforts underway now (simple binary, asn.1, google protocol buffers) a JSON encoding spec makes a great deal of sense.
Can you lead this group if GTC approves?
Hello
We are currently working on a FIXML API for trade registration.
We choose FIXML over FIX to gain better readability on the cost of 70% (i think someone stated) bigger data chunks.I was wondering, if anyone has concidered making a JSON equivalent to the FIXML? JSON is a readable standard just like XML and is widely used in tons of applications (e.g. JavaScript in browsers, data format in many document oriented databases).
I made an example of how a JSON equivalent to a FIXML might look:
FIXML:
JSON: (e.g. FIXON):
{
v: “4.4”,
ExecRep: {
SID=“AAB”,
TID=“BBC”
Exec: [
{ id=“L1” },
{ id=“L2” }
]
}
}The JSON version only uses 80% of the space of the FIXML version.
If FIXML uses 70% more than fix, my calculations show, that JSON would only be 36% more then FIX. This would give nearly the same effective memory usage as FIX and still keeping the data very human readable.I look forward to hear your oppinions on this.
Thankyou in advance
/Stephan Ryer
Hello,
One of the “trickiest” parts of translating from XML to JSON is that XML supports attributes whereas JSON does not. For example, there is no direct correlation between <name lang="en-us">Sam</name> and JSON. Most libraries that serialize between the two would turn that XML into JSON like this:
``
{
“name”: {
“attrs”: {
“lang”: “en-us”
},
“value”: “Sam”
}
}
‘’
Here is some example JSON from nested XML:
``
{
“name”: {
“_attrs”: {
“lang”: “en-us”
},
“_value”: {
“first”: {
“_value”: “Sam”
},
“last”: {
“_value”: “Bisbee”
}
}
}
}
‘’
It’s a bit hacky because of the need to support attributes.
Cheers.
Hello
We are currently working on a FIXML API for trade registration.
We choose FIXML over FIX to gain better readability on the cost of 70% (i think someone stated) bigger data chunks.I was wondering, if anyone has concidered making a JSON equivalent to the FIXML? JSON is a readable standard just like XML and is widely used in tons of applications (e.g. JavaScript in browsers, data format in many document oriented databases).
I made an example of how a JSON equivalent to a FIXML might look:
FIXML:
JSON: (e.g. FIXON):
{
v: “4.4”,
ExecRep: {
SID=“AAB”,
TID=“BBC”
Exec: [
{ id=“L1” },
{ id=“L2” }
]
}
}The JSON version only uses 80% of the space of the FIXML version.
If FIXML uses 70% more than fix, my calculations show, that JSON would only be 36% more then FIX. This would give nearly the same effective memory usage as FIX and still keeping the data very human readable.I look forward to hear your oppinions on this.
Thankyou in advance
/Stephan Ryer
I think a discussion on whether we should be going FIXML ↔ JSON/BSON or FIX repository (definition) ↔ JSON/BSON is worth having.
In the other compatibility / integration encodings - we are focused on FIX ↔ (GPB, Simple Binary, ASN.1). With FIXML encoding being viewed as one of the many FIX ↔ * Encodings.
I am concerned, as one of the authors of the optimized FIXML, that we continue to proliferate this approach of optimization. Had we had a reasonable binary encoding of XML available at the time, we likely would have simply stayed with the original FIXML definition created by John Goeller, et al in the late 1990s. As it was, there was no standard agreed upon XML binary encoding, so we made fit-for-purpose optimizations (abbreviations including overlapping abbreviation names for different fields) and the introduction of attributes to carry data. XML as it exists is not an optimal protocol for high volume messaging, and much of finance sees high message rates.
Hello,
One of the “trickiest” parts of translating from XML to JSON is that XML supports attributes whereas JSON does not. For example, there is no direct correlation between
<name lang="en-us">Sam</name>and JSON. Most libraries that serialize between the two would turn that XML into JSON like this:``
{
“name”: {
“attrs”: {
“lang”: “en-us”
},
“value”: “Sam”
}
}
‘’Here is some example JSON from nested XML:
``
{
“name”: {
“_attrs”: {
“lang”: “en-us”
},
“_value”: {
“first”: {
“_value”: “Sam”
},
“last”: {
“_value”: “Bisbee”
}
}
}
}
‘’It’s a bit hacky because of the need to support attributes.
Cheers.
Hello
We are currently working on a FIXML API for trade registration.
We choose FIXML over FIX to gain better readability on the cost of 70% (i think someone stated) bigger data chunks.I was wondering, if anyone has concidered making a JSON equivalent to the FIXML? JSON is a readable standard just like XML and is widely used in tons of applications (e.g. JavaScript in browsers, data format in many document oriented databases).
I made an example of how a JSON equivalent to a FIXML might look:
FIXML:
JSON: (e.g. FIXON):
{
v: “4.4”,
ExecRep: {
SID=“AAB”,
TID=“BBC”
Exec: [
{ id=“L1” },
{ id=“L2” }
]
}
}The JSON version only uses 80% of the space of the FIXML version.
If FIXML uses 70% more than fix, my calculations show, that JSON would only be 36% more then FIX. This would give nearly the same effective memory usage as FIX and still keeping the data very human readable.I look forward to hear your oppinions on this.
Thankyou in advance
/Stephan Ryer
I think you, Sam, has a good point regarding issues with trivial transformations from XML to JSON, though the problem may not be that big as FIXML primarily uses attributes only (i.e. rarely uses text elements). And I must also agree with you, Jim, that implementing a JSON-format is no longer necessarily a simple, brilliant idea as we initially saw it. It requires more thoughts and discussions in order to determine if this is a good idea.
I think a discussion on whether we should be going FIXML ↔ JSON/BSON or FIX repository (definition) ↔ JSON/BSON is worth having.
In the other compatibility / integration encodings - we are focused on FIX ↔ (GPB, Simple Binary, ASN.1). With FIXML encoding being viewed as one of the many FIX ↔ * Encodings.
I am concerned, as one of the authors of the optimized FIXML, that we continue to proliferate this approach of optimization. Had we had a reasonable binary encoding of XML available at the time, we likely would have simply stayed with the original FIXML definition created by John Goeller, et al in the late 1990s. As it was, there was no standard agreed upon XML binary encoding, so we made fit-for-purpose optimizations (abbreviations including overlapping abbreviation names for different fields) and the introduction of attributes to carry data. XML as it exists is not an optimal protocol for high volume messaging, and much of finance sees high message rates.
Hello,
One of the “trickiest” parts of translating from XML to JSON is that XML supports attributes whereas JSON does not. For example, there is no direct correlation between
<name lang="en-us">Sam</name>and JSON. Most libraries that serialize between the two would turn that XML into JSON like this:``
{
“name”: {
“attrs”: {
“lang”: “en-us”
},
“value”: “Sam”
}
}
‘’Here is some example JSON from nested XML:
``
{
“name”: {
“_attrs”: {
“lang”: “en-us”
},
“_value”: {
“first”: {
“_value”: “Sam”
},
“last”: {
“_value”: “Bisbee”
}
}
}
}
‘’It’s a bit hacky because of the need to support attributes.
Cheers.
Hello
We are currently working on a FIXML API for trade registration.
We choose FIXML over FIX to gain better readability on the cost of 70% (i think someone stated) bigger data chunks.I was wondering, if anyone has concidered making a JSON equivalent to the FIXML? JSON is a readable standard just like XML and is widely used in tons of applications (e.g. JavaScript in browsers, data format in many document oriented databases).
I made an example of how a JSON equivalent to a FIXML might look:
FIXML:
JSON: (e.g. FIXON):
{
v: “4.4”,
ExecRep: {
SID=“AAB”,
TID=“BBC”
Exec: [
{ id=“L1” },
{ id=“L2” }
]
}
}The JSON version only uses 80% of the space of the FIXML version.
If FIXML uses 70% more than fix, my calculations show, that JSON would only be 36% more then FIX. This would give nearly the same effective memory usage as FIX and still keeping the data very human readable.I look forward to hear your oppinions on this.
Thankyou in advance
/Stephan Ryer
A JSON/BSON encoding would have great value though. Let’s figure a way to get it started up.
Hello
Excellent and rich proposition!!
Based on benchmark results between protocols XML, JSON and YAML performed by Ruben Fonseca and Alberto Simões proposition forum is highly appropriate, since JSON and YAML has significant advantage over the XML, so on FIXML. Added to this the evolution of the concept of prevalence, from the pioneering Prevayler, which led to the rise of the NoSQL movement and products like MongoDB or CouchDB for direct manipulation of JSON / BSON a natural way to FIXON.
We made a trivial conversion of FIXML ==> JSON ==> YAML based on the examples provided by the FIX Protocol 4.4 to check whether the semantics is preserved.
I believe no other API FIX session layer are encapsulated in while the search for higher processing performance signfica also lower energy costs in data centers there since they are based on models with operating costs before the advent of Facebook Open Source Datacenter therefore with high energy consumption, and in this case, it is always good to remember the perspective Gartner and IDC for large data centers with intensive cooling systems of the type chiller.
"STAMFORD, Conn., November 29, 2006
Gartner Says 50 Percent of Data Centers Will Have Insufficient Power and Cooling Capacity by 2008
Gartner Analysts Examine Data Center Power and Cooling Challenges During Gartner’s 25th Annual Data Center Conference, November 28 - December 1, in Las Vegas
Organizations are increasingly deploying more computing power, but, by 2008, 50 percent of current data centers will have insufficient power and cooling capacity to meet the demands of high-density equipment, according to Gartner, Inc."
Thank you in advance
José S Sobrinho
Hello
We are currently working on a FIXML API for trade registration.
We choose FIXML over FIX to gain better readability on the cost of 70% (i think someone stated) bigger data chunks.I was wondering, if anyone has concidered making a JSON equivalent to the FIXML? JSON is a readable standard just like XML and is widely used in tons of applications (e.g. JavaScript in browsers, data format in many document oriented databases).
I made an example of how a JSON equivalent to a FIXML might look:
FIXML:
JSON: (e.g. FIXON):
{
v: “4.4”,
ExecRep: {
SID=“AAB”,
TID=“BBC”
Exec: [
{ id=“L1” },
{ id=“L2” }
]
}
}The JSON version only uses 80% of the space of the FIXML version.
If FIXML uses 70% more than fix, my calculations show, that JSON would only be 36% more then FIX. This would give nearly the same effective memory usage as FIX and still keeping the data very human readable.I look forward to hear your oppinions on this.
Thankyou in advance
/Stephan Ryer
Hi All,
The original post in this thread dates back to August 2012. Did this progress or fade away? I am working on a small project that uses FIX, FIXML and may use JSON/BSON so I would prefer to understand the state of the art before reinventing the wheel.
Cheers,
John
John,
no tangible work has been done on JSON/BSON so far. We have set up the organisation structure to do this by having created separate subgroups of the High Performance Working Group (HPWG), one for each encoding (SBE, GPB, ASN.1, FIXML, FIXTV, FAST). It is easy to set up another subgroup for JSON/BSON and ask for interested parties to participate. It needst to be driven by someone from the community and would follow the standards processes currently being used for SBE and others, i.e. Technical Standards Proposal and Release Candidates with 90 day public review periods after HPWG review and subsequent submission to FIX Global Technical Committee.
Regards,
Hanno.