Imported from previous forum
[ original email was from John Harris - john.harris@bondmart.com ]
The data dictionary contains over nine thousand lines of descriptive information, including over five hundred sets of enumerated values. Some of these sets have over one hundred members.
It is fair to say that substantially all of this information is useful to someone - otherwise, it wouldn’t be there. At some level the information represents business requirements. But the information is also filled with errors, inconsistencies, and ambiguities.
Much of the information is static or “reference” data that likely should not be passed around through high-performance interfaces. Instead, to the extent necessary, messages should contain pointers to golden copies of this information.
On the last call, the question arose: how do we specify the requirements for the new protocol. I advocated beginning with use cases, but now think that was bad advice: we should cull the requirements in large part from FIX 5.0 SP2. (We can’t cull all the requirements from the latest spec, because if it met the requirements fully, we wouldn’t be having this conversation.)
Doing this right will be an enormous amount of work.
Do we have the right people and organizational framework in place?
I don’t think so.
We’re moving at a snail’s pace. Let’s share ideas on how to organize then effort, source the required labor and expertise, and get after it.
Otherwise, this new protocol effort will founder.
John,
I have edited your post in an attempt to create a response that is short and concise. Apologies if I have removed or changed anything that has bearing on my response. Please find my comments inline.
/Rolf
The [FIX] data dictionary contains:
over nine thousand lines of descriptive information,
over five hundred sets of enumerated values.
Some of these sets have over one hundred members.… substantially all of this information is useful to someone
… the information represents business requirements.
Agreed, and I believe we are expected to relate to the existing dictionary.
… [It is] filled with errors, inconsistencies, and ambiguities.
This comment has little meaning without more specific details on:
- What it means to the HPI effort
- How we should deal with the (perceived) shortcomings of the dictionary.
How do you propose that we should handle this?
… [How] do we specify the requirements for the new protocol.
I advocated beginning with use cases, but now think that was bad advice:
- We should cull the requirements in large part from FIX 5.0 SP2.
I think we need to do both in parallel.
A few examples that have been discussed recently:
- Exec reports are large because of the number of mandatory fields.
- New Order Single contains fields that are not relevant in all situations.
It has been suggested that we consider:
. Making some now mandatory fields optional.
. Add new message types that can be used for some use cases.
Doing this right will be an enormous amount of work.
Agreed, I think we should try to do this incrementally.
We need to test our ideas and assumptions.
By focusing on a few core use cases we can:
- Provide preliminary specs for implementation
- Prepare test data sets
- Prepare and execute test cases
- Analyze test results
Do we have the right people and organizational framework in place?
I don’t think so.
Let’s share ideas on how to organize then effort,
source the required labor and expertise, and get after it.
The resources in use just now are volunteers.
This work is largely funded by member organizations.
FPL provides wg admin incl conf bridge, forum admin etc.
There is currently no funding for external wg resources.
“… source the required labor and expertise …”
may require additional funding.
Do you have any specific suggestions?
Otherwise, this new protocol effort will founder.
I strongly believe that a standard HPI protocol is needed.
If this effort fails, it will be followed by another.
[ original email was from John Harris - john.harris@bondmart.com ]
Rolf,
Your edits were fine - thank you - and your questions and comments are helpful. Please see my responses inline as well.
Best,
John
John,
I have edited your post in an attempt to create a response that is short and concise. Apologies if I have removed or changed anything that has bearing on my response. Please find my comments inline.
/Rolf
The [FIX] data dictionary contains:
over nine thousand lines of descriptive information,
over five hundred sets of enumerated values.
Some of these sets have over one hundred members.… substantially all of this information is useful to someone
… the information represents business requirements.Agreed, and I believe we are expected to relate to the existing dictionary.
Expected by whom? Setting aside whether relating to the existing dictionary (or, more generally, range of semantic possibilities) is wise - it may well be - does the group’s charter implicitly or explicitly require such relation? I ask just to confirm to what extent the group is truly free to start fresh under the auspices of FPL. And just so there is no misunderstanding on this point, I do want FPL’s encouragement, support, and endorsement of the effort.
… [It is] filled with errors, inconsistencies, and ambiguities.
This comment has little meaning without more specific details on:
- What it means to the HPI effort
- How we should deal with the (perceived) shortcomings of the dictionary.
These “errors, inconsistencies, and ambiguities” are not just “perceived,” but actual. Reading or using the specification in any reasonable way without becoming aware of these issues is impossible. As a volunteer who could have done more and better, I take responsibility for some of these defects, but more to the point, if we produce the HPI specifications using generally the same process, tools, and resources that led ultimately to the creation of FIX 5.0 SP2, we may well wind up with a similar set of defects (though also with a similar set of the wonderful attributes of the protocol). None of my remarks should be construed as negative criticism of the efforts or abilities of any volunteer, who well deserve only gratitude and praise.
I believe we should correct and complete the existing dictionary, no matter how painful that may be. First, FIX as we know it isn’t going away, so we may as well get it right. Second, the HPI effort needs to extract as much wisdom as possible from the existing dictionary. Correcting and completing the current dictionary will help that effort.
How do you propose that we should handle this?
My best guess at the moment about how to repair and complete the dictionary is to create a massive table with these column headings: Message Type, Component Block(s), Tag, Field Name, Data Type, Description or Enumerated Value. Where a field appears directly in a message, the value of the record entry in the Component Block column would be null. We would have multiple Component Block columns, the number of such columns equaling the extent of nesting of component blocks in the most extreme case. As in the first Component Block column, where a Component Block contains a Component Block, the values of the corresponding record entries would be null. We can then run a number of operations and brute-force procedures on the table to clean and complete the dictionary. We will also come to understand some things about FIX semantics that are not obvious at the moment. I could create such a table using brute force and will give it a try at least as a validation step, but I will check with some friends to see if they can automate the process a bit.
I believe Microsoft Word has outlived its usefulness as a tool for creating, managing, and maintaining the specification. I have proposed a wiki and won’t belabor that point here. But I know that a different tool is needed. What is happening now is that defects in the spec are being propagated, virus-like, into online dictionaries and implementation specifications. It’s time for that to stop.
… [How] do we specify the requirements for the new protocol.
I advocated beginning with use cases, but now think that was bad advice:
- We should cull the requirements in large part from FIX 5.0 SP2.
I think we need to do both in parallel.
A few examples that have been discussed recently:
- Exec reports are large because of the number of mandatory fields.
- New Order Single contains fields that are not relevant in all situations.
It has been suggested that we consider:
. Making some now mandatory fields optional.
. Add new message types that can be used for some use cases.
No disagreement.
Doing this right will be an enormous amount of work.
Agreed, I think we should try to do this incrementally.
Okay, but’s let’s set a goal of having the first, FPL-recommended, HPI spec ready in no more than one year from this date. That implies a constrained scope and will require a collaboration tool other than Word, among other things.
We need to test our ideas and assumptions.
By focusing on a few core use cases we can:
- Provide preliminary specs for implementation
- Prepare test data sets
- Prepare and execute test cases
- Analyze test results
Agreed. I have a draft, public domain, text version of an “Automated Trading Protocol” that BondMart created and circulated several years ago at the suggestion of some well-known, algorithmic trading firms. For better or worse, it is fixed-income-exchange oriented and perhaps naive in multiple respects, but it did pass conceptual muster with several of these firms. Unfortunately, it is in Microsoft Word format 
I will post it in a wiki under Creative Commons license for whatever benefit it may provide this effort (which may be minimal).
Do we have the right people and organizational framework in place?
I don’t think so.
Let’s share ideas on how to organize then effort,
source the required labor and expertise, and get after it.The resources in use just now are volunteers.
This work is largely funded by member organizations.
I am not a member or affiliated with a member firm. My efforts on the protocol are funded by my businesses. We need to open this development effort up to everyone in the world who has a sincere interest in and ability to help.
FPL provides wg admin incl conf bridge, forum admin etc.
There is currently no funding for external wg resources.“… source the required labor and expertise …”
may require additional funding.Do you have any specific suggestions?
Yes. I have made multiple, specific suggestions in this forum and on the calls. Pursue an ambitious, world-changing goal - creates excitement and makes the effort worthwhile. Invite and encourage everyone to participate - sources expertise and labor, and promotes acceptance. Get kids involved - even teenagers; before we are done, they will be creating the next algorithms that use the protocol. Collaborate around a wiki that anyone can edit, at least until that is proven unworkable. We don’t need more money or permanent staff - at least not yet - to do this.
Otherwise, this new protocol effort will founder.
I strongly believe that a standard HPI protocol is needed.
If this effort fails, it will be followed by another.
Agreed.
John,
pls find my comments below.
/Rolf
I believe we are expected to relate to the existing dictionary.
Expected by whom?
I was a bit terse.
I meant by those who will consider to adapt the protocol.
These “errors, inconsistencies, and ambiguities” are not just
“perceived,” but actual. Reading or using the specification in
any reasonable way without becoming aware of these issues is
impossible.
There are certainly errors in the FIX spec (as in most specs).
I find it usable though and I believe errors can be handled as we go.
That said, there is always room for improvement.
I believe we should correct and complete the existing dictionary,
no matter how painful that may be. First, FIX as we know it isn’t
going away, so we may as well get it right.
I don’t think this should be part of the HPI effort.
Second, the HPI effort needs to extract as much wisdom as possible
from the existing dictionary. Correcting and completing the current
dictionary will help that effort.
We should ask the repo wg for assistance.
My best guess at the moment about how to repair and complete the
dictionary is to create a massive table with these column headings:
…I believe Microsoft Word has outlived its usefulness as a tool for
creating, managing, and maintaining the specification.
I believe you are misinformed about how new spec versions are created.
I’ll let someone in the repo wg to describe the process.
Agreed, I think we should try to do this incrementally.
Okay, but’s let’s set a goal of having the first, FPL-recommended,
HPI spec ready in no more than one year from this date.
I believe we can meet this goal.
That implies a constrained scope …
Not sure about this, but we need to be prepared for it.
My current view is that we will have issues in testing a draft spec.
and will require a collaboration tool other than Word …
Or perhaps a combination of a collaboration tool and word.
The word version of the draft spec being handled by an editor.
I have a draft, public domain, text version of an “Automated Trading
Protocol” that BondMart created and circulated several years ago at
the suggestion of some well-known, algorithmic trading firms. …
I will post it in a wiki under Creative Commons license for whatever
benefit it may provide this effort (which may be minimal).
I’m looking forward to reading it.
I am not a member or affiliated with a member firm.
You should consider becoming a member.
This wg is part of the FPL.
My efforts on the protocol are funded by my businesses.
This is no different from my and most other people’s involvement.
We need to open this development effort up to everyone in the
world who has a sincere interest in and ability to help.
Let’s not confuse the issues here.
This is an FPL effort in part funded by FPL and its members.
It is open for people to contribute.
I don’t agree with your earlier proposals to provide an entirely
open wiki, but that is about mechanism not policy.
Do you have any specific suggestions?
Yes. I have made multiple, specific suggestions in this forum and
on the calls.[1] Pursue an ambitious, world-changing goal - creates excitement
and makes the effort worthwhile.
Not specific. This is marketing more than anything else.
I’ll test it on a few FPL members and report back.
[2] Invite and encourage everyone to participate - sources expertise
and labor, and promotes acceptance.
Not specific in my view.
Invite, encourage - how, setting what expectations?
At one level this is obvious but essentially meaningless.
Of course we encourage participation in the effort as defined.
I don’t encourage participation as a social event.
We have a task to complete. There is little utility for the wg in
someone using the forum as a personal blog.
[3] Get kids involved - even teenagers; before we are done, they will
be creating the next algorithms that use the protocol.
Not specific in my view. How, what?
Young people can contribute, but not just because they are young.
I wasn’t even sure you were serious. Am I missing something here?
[4] Collaborate around a wiki that anyone can edit, at least until
that is proven unworkable.
This proposal is specific, but as I stated earlier, I believe your
reference wiki proves it unworkable.
[ original email was from John Harris - john.harris@bondmart.com ]
Thank you, Rolf. Let me just summarize and respond to those aspects of your reply that appear to require further response from me. I hope others will share their thoughts as well.
– On when and by whom errors in the FIX spec should be corrected:
I agree this falls outside the charter for HPIWG. I have volunteered for the job and will complete it on my own, with the help of other volunteers.
– On Word as a collaboration tool:
I have no objection to using Word among other tools. I can safely predict, though, that to the extent Word is the primary repository of group documents, progress will be unnecessarily and unhelpfully slow and participation unnecessarily and unhelpfully constrained. Case in point: the latest version of the group’s scope document is sitting on someone’s hard drive - no one else can read, comprehend, reference, or contribute to it. All Word documents suffer from that defect. Many volunteers are best able to contribute to FIX at night and on weekends. When we keep important information in Word, we hamper their efforts. The current spec lives in multiple Word documents. Searching for information across multiple Word files is tedious at best. Vendors have responded with online, hyperlinked dictionaries, but these tend to perpetuate the errors in the original and, understandably, provide no means of correcting errors in the original. The only benefit I can deduce from continued reliance on Word is that it enables a small number of people to control information. Such control is helpful in some contexts, not in others. With respect to producing an open communications standard aiming for widespread adoption and network effects, Word is a poor choice as primary tool of production.
– On the goal of the effort:
We may well differ on goals. I have articulated examples of communications that I would like to see the new protocol facilitate that your or others may find out of scope, uninteresting, etc. I support the efforts of the working group even if its ambitions are more limited than I would prefer.
– On how to encourage and set expectations for broad, open participation:
When the time comes, I will draft a specific proposal in that regard.
– On whether I was serious about encouraging “kids” and “teenagers” to help:
I was speaking metaphorically, but am quite serious about the concept of encouraging a wide swath of people who may never have heard of FIX to get involved, including relative youngsters. What we know today as Microsoft, Facebook, Firefox, Napster, and WordPress were all created by teenagers. I want to source ideas and help from outside the usual ponds of FIX contributors.
– On using an open wiki:
I have proposed using an open wiki for protocol development; warned that vandalism is inevitable, but controllable; advised that wikis have means for controlling miscreant acts. You appear to disagree with that approach. Neither of us can be proven correct at this juncture. If FPL does not want to facilitate an open wiki under its domain, I will create an open, public-domain wiki under an innocuous URL at my expense, invite participation, and soon enough we’ll learn whether an open wiki truly is helpful to the protocol.
Best,
John
John,
pls find my comments below.
/Rolf
I believe we are expected to relate to the existing dictionary.
Expected by whom?I was a bit terse.
I meant by those who will consider to adapt the protocol.These “errors, inconsistencies, and ambiguities” are not just
“perceived,” but actual. Reading or using the specification in
any reasonable way without becoming aware of these issues is
impossible.There are certainly errors in the FIX spec (as in most specs).
I find it usable though and I believe errors can be handled as we go.
That said, there is always room for improvement.I believe we should correct and complete the existing dictionary,
no matter how painful that may be. First, FIX as we know it isn’t
going away, so we may as well get it right.I don’t think this should be part of the HPI effort.
Second, the HPI effort needs to extract as much wisdom as possible
from the existing dictionary. Correcting and completing the current
dictionary will help that effort.We should ask the repo wg for assistance.
My best guess at the moment about how to repair and complete the
dictionary is to create a massive table with these column headings:
…I believe Microsoft Word has outlived its usefulness as a tool for
creating, managing, and maintaining the specification.I believe you are misinformed about how new spec versions are created.
I’ll let someone in the repo wg to describe the process.Agreed, I think we should try to do this incrementally.
Okay, but’s let’s set a goal of having the first, FPL-recommended,
HPI spec ready in no more than one year from this date.I believe we can meet this goal.
That implies a constrained scope …
Not sure about this, but we need to be prepared for it.
My current view is that we will have issues in testing a draft spec.and will require a collaboration tool other than Word …
Or perhaps a combination of a collaboration tool and word.
The word version of the draft spec being handled by an editor.I have a draft, public domain, text version of an “Automated Trading
Protocol” that BondMart created and circulated several years ago at
the suggestion of some well-known, algorithmic trading firms. …
I will post it in a wiki under Creative Commons license for whatever
benefit it may provide this effort (which may be minimal).I’m looking forward to reading it.
I am not a member or affiliated with a member firm.
You should consider becoming a member.
This wg is part of the FPL.My efforts on the protocol are funded by my businesses.
This is no different from my and most other people’s involvement.
We need to open this development effort up to everyone in the
world who has a sincere interest in and ability to help.Let’s not confuse the issues here.
This is an FPL effort in part funded by FPL and its members.
It is open for people to contribute.I don’t agree with your earlier proposals to provide an entirely
open wiki, but that is about mechanism not policy.Do you have any specific suggestions?
Yes. I have made multiple, specific suggestions in this forum and
on the calls.[1] Pursue an ambitious, world-changing goal - creates excitement
and makes the effort worthwhile.Not specific. This is marketing more than anything else.
I’ll test it on a few FPL members and report back.[2] Invite and encourage everyone to participate - sources expertise
and labor, and promotes acceptance.Not specific in my view.
Invite, encourage - how, setting what expectations?At one level this is obvious but essentially meaningless.
Of course we encourage participation in the effort as defined.
I don’t encourage participation as a social event.
We have a task to complete. There is little utility for the wg in
someone using the forum as a personal blog.[3] Get kids involved - even teenagers; before we are done, they will
be creating the next algorithms that use the protocol.Not specific in my view. How, what?
Young people can contribute, but not just because they are young.
I wasn’t even sure you were serious. Am I missing something here?[4] Collaborate around a wiki that anyone can edit, at least until
that is proven unworkable.This proposal is specific, but as I stated earlier, I believe your
reference wiki proves it unworkable.
[ original email was from Khody Azmoon - kazmoon@algotm.com ]
Any update or has this become inactive?
Khody
Thank you, Rolf. Let me just summarize and respond to those aspects of your reply that appear to require further response from me. I hope others will share their thoughts as well.
– On when and by whom errors in the FIX spec should be corrected:
I agree this falls outside the charter for HPIWG. I have volunteered for the job and will complete it on my own, with the help of other volunteers.
– On Word as a collaboration tool:
I have no objection to using Word among other tools. I can safely predict, though, that to the extent Word is the primary repository of group documents, progress will be unnecessarily and unhelpfully slow and participation unnecessarily and unhelpfully constrained. Case in point: the latest version of the group’s scope document is sitting on someone’s hard drive - no one else can read, comprehend, reference, or contribute to it. All Word documents suffer from that defect. Many volunteers are best able to contribute to FIX at night and on weekends. When we keep important information in Word, we hamper their efforts. The current spec lives in multiple Word documents. Searching for information across multiple Word files is tedious at best. Vendors have responded with online, hyperlinked dictionaries, but these tend to perpetuate the errors in the original and, understandably, provide no means of correcting errors in the original. The only benefit I can deduce from continued reliance on Word is that it enables a small number of people to control information. Such control is helpful in some contexts, not in others. With respect to producing an open communications standard aiming for widespread adoption and network effects, Word is a poor choice as primary tool of production.
– On the goal of the effort:
We may well differ on goals. I have articulated examples of communications that I would like to see the new protocol facilitate that your or others may find out of scope, uninteresting, etc. I support the efforts of the working group even if its ambitions are more limited than I would prefer.
– On how to encourage and set expectations for broad, open participation:
When the time comes, I will draft a specific proposal in that regard.
– On whether I was serious about encouraging “kids” and “teenagers” to help:
I was speaking metaphorically, but am quite serious about the concept of encouraging a wide swath of people who may never have heard of FIX to get involved, including relative youngsters. What we know today as Microsoft, Facebook, Firefox, Napster, and WordPress were all created by teenagers. I want to source ideas and help from outside the usual ponds of FIX contributors.
– On using an open wiki:
I have proposed using an open wiki for protocol development; warned that vandalism is inevitable, but controllable; advised that wikis have means for controlling miscreant acts. You appear to disagree with that approach. Neither of us can be proven correct at this juncture. If FPL does not want to facilitate an open wiki under its domain, I will create an open, public-domain wiki under an innocuous URL at my expense, invite participation, and soon enough we’ll learn whether an open wiki truly is helpful to the protocol.
Best,
JohnJohn,
pls find my comments below.
/Rolf
I believe we are expected to relate to the existing dictionary.
Expected by whom?I was a bit terse.
I meant by those who will consider to adapt the protocol.These “errors, inconsistencies, and ambiguities” are not just
“perceived,” but actual. Reading or using the specification in
any reasonable way without becoming aware of these issues is
impossible.There are certainly errors in the FIX spec (as in most specs).
I find it usable though and I believe errors can be handled as we go.
That said, there is always room for improvement.I believe we should correct and complete the existing dictionary,
no matter how painful that may be. First, FIX as we know it isn’t
going away, so we may as well get it right.I don’t think this should be part of the HPI effort.
Second, the HPI effort needs to extract as much wisdom as possible
from the existing dictionary. Correcting and completing the current
dictionary will help that effort.We should ask the repo wg for assistance.
My best guess at the moment about how to repair and complete the
dictionary is to create a massive table with these column headings:
…I believe Microsoft Word has outlived its usefulness as a tool for
creating, managing, and maintaining the specification.I believe you are misinformed about how new spec versions are created.
I’ll let someone in the repo wg to describe the process.Agreed, I think we should try to do this incrementally.
Okay, but’s let’s set a goal of having the first, FPL-recommended,
HPI spec ready in no more than one year from this date.I believe we can meet this goal.
That implies a constrained scope …
Not sure about this, but we need to be prepared for it.
My current view is that we will have issues in testing a draft spec.and will require a collaboration tool other than Word …
Or perhaps a combination of a collaboration tool and word.
The word version of the draft spec being handled by an editor.I have a draft, public domain, text version of an “Automated Trading
Protocol” that BondMart created and circulated several years ago at
the suggestion of some well-known, algorithmic trading firms. …
I will post it in a wiki under Creative Commons license for whatever
benefit it may provide this effort (which may be minimal).I’m looking forward to reading it.
I am not a member or affiliated with a member firm.
You should consider becoming a member.
This wg is part of the FPL.My efforts on the protocol are funded by my businesses.
This is no different from my and most other people’s involvement.
We need to open this development effort up to everyone in the
world who has a sincere interest in and ability to help.Let’s not confuse the issues here.
This is an FPL effort in part funded by FPL and its members.
It is open for people to contribute.I don’t agree with your earlier proposals to provide an entirely
open wiki, but that is about mechanism not policy.Do you have any specific suggestions?
Yes. I have made multiple, specific suggestions in this forum and
on the calls.[1] Pursue an ambitious, world-changing goal - creates excitement
and makes the effort worthwhile.Not specific. This is marketing more than anything else.
I’ll test it on a few FPL members and report back.[2] Invite and encourage everyone to participate - sources expertise
and labor, and promotes acceptance.Not specific in my view.
Invite, encourage - how, setting what expectations?At one level this is obvious but essentially meaningless.
Of course we encourage participation in the effort as defined.
I don’t encourage participation as a social event.
We have a task to complete. There is little utility for the wg in
someone using the forum as a personal blog.[3] Get kids involved - even teenagers; before we are done, they will
be creating the next algorithms that use the protocol.Not specific in my view. How, what?
Young people can contribute, but not just because they are young.
I wasn’t even sure you were serious. Am I missing something here?[4] Collaborate around a wiki that anyone can edit, at least until
that is proven unworkable.This proposal is specific, but as I stated earlier, I believe your
reference wiki proves it unworkable.
Khody, are you referring to the wg as a whole or to my discussion with John re dev process?
/Rolf
Any update or has this become inactive?
Khody
Thank you, Rolf. Let me just summarize and respond to those aspects of your reply that appear to require further response from me. I hope others will share their thoughts as well.
– On when and by whom errors in the FIX spec should be corrected:
I agree this falls outside the charter for HPIWG. I have volunteered for the job and will complete it on my own, with the help of other volunteers.
– On Word as a collaboration tool:
I have no objection to using Word among other tools. I can safely predict, though, that to the extent Word is the primary repository of group documents, progress will be unnecessarily and unhelpfully slow and participation unnecessarily and unhelpfully constrained. Case in point: the latest version of the group’s scope document is sitting on someone’s hard drive - no one else can read, comprehend, reference, or contribute to it. All Word documents suffer from that defect. Many volunteers are best able to contribute to FIX at night and on weekends. When we keep important information in Word, we hamper their efforts. The current spec lives in multiple Word documents. Searching for information across multiple Word files is tedious at best. Vendors have responded with online, hyperlinked dictionaries, but these tend to perpetuate the errors in the original and, understandably, provide no means of correcting errors in the original. The only benefit I can deduce from continued reliance on Word is that it enables a small number of people to control information. Such control is helpful in some contexts, not in others. With respect to producing an open communications standard aiming for widespread adoption and network effects, Word is a poor choice as primary tool of production.
– On the goal of the effort:
We may well differ on goals. I have articulated examples of communications that I would like to see the new protocol facilitate that your or others may find out of scope, uninteresting, etc. I support the efforts of the working group even if its ambitions are more limited than I would prefer.
– On how to encourage and set expectations for broad, open participation:
When the time comes, I will draft a specific proposal in that regard.
– On whether I was serious about encouraging “kids” and “teenagers” to help:
I was speaking metaphorically, but am quite serious about the concept of encouraging a wide swath of people who may never have heard of FIX to get involved, including relative youngsters. What we know today as Microsoft, Facebook, Firefox, Napster, and WordPress were all created by teenagers. I want to source ideas and help from outside the usual ponds of FIX contributors.
– On using an open wiki:
I have proposed using an open wiki for protocol development; warned that vandalism is inevitable, but controllable; advised that wikis have means for controlling miscreant acts. You appear to disagree with that approach. Neither of us can be proven correct at this juncture. If FPL does not want to facilitate an open wiki under its domain, I will create an open, public-domain wiki under an innocuous URL at my expense, invite participation, and soon enough we’ll learn whether an open wiki truly is helpful to the protocol.
Best,
John
[ original email was from Khody Azmoon - kazmoon@algotm.com ]
Rolf, to your discussion with John.
Khody
Khody, are you referring to the wg as a whole or to my discussion with John re dev process?
/Rolf
Any update or has this become inactive?
Khody
Thank you, Rolf. Let me just summarize and respond to those aspects of your reply that appear to require further response from me. I hope others will share their thoughts as well.
– On when and by whom errors in the FIX spec should be corrected:
I agree this falls outside the charter for HPIWG. I have volunteered for the job and will complete it on my own, with the help of other volunteers.
– On Word as a collaboration tool:
I have no objection to using Word among other tools. I can safely predict, though, that to the extent Word is the primary repository of group documents, progress will be unnecessarily and unhelpfully slow and participation unnecessarily and unhelpfully constrained. Case in point: the latest version of the group’s scope document is sitting on someone’s hard drive - no one else can read, comprehend, reference, or contribute to it. All Word documents suffer from that defect. Many volunteers are best able to contribute to FIX at night and on weekends. When we keep important information in Word, we hamper their efforts. The current spec lives in multiple Word documents. Searching for information across multiple Word files is tedious at best. Vendors have responded with online, hyperlinked dictionaries, but these tend to perpetuate the errors in the original and, understandably, provide no means of correcting errors in the original. The only benefit I can deduce from continued reliance on Word is that it enables a small number of people to control information. Such control is helpful in some contexts, not in others. With respect to producing an open communications standard aiming for widespread adoption and network effects, Word is a poor choice as primary tool of production.
– On the goal of the effort:
We may well differ on goals. I have articulated examples of communications that I would like to see the new protocol facilitate that your or others may find out of scope, uninteresting, etc. I support the efforts of the working group even if its ambitions are more limited than I would prefer.
– On how to encourage and set expectations for broad, open participation:
When the time comes, I will draft a specific proposal in that regard.
– On whether I was serious about encouraging “kids” and “teenagers” to help:
I was speaking metaphorically, but am quite serious about the concept of encouraging a wide swath of people who may never have heard of FIX to get involved, including relative youngsters. What we know today as Microsoft, Facebook, Firefox, Napster, and WordPress were all created by teenagers. I want to source ideas and help from outside the usual ponds of FIX contributors.
– On using an open wiki:
I have proposed using an open wiki for protocol development; warned that vandalism is inevitable, but controllable; advised that wikis have means for controlling miscreant acts. You appear to disagree with that approach. Neither of us can be proven correct at this juncture. If FPL does not want to facilitate an open wiki under its domain, I will create an open, public-domain wiki under an innocuous URL at my expense, invite participation, and soon enough we’ll learn whether an open wiki truly is helpful to the protocol.
Best,
John