[This message was posted by Anders Furuhed of Pantor Engineering <[email protected]> to the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply to it on-line at http://fixprotocol.org/discuss/read/f802ffd6 - PLEASE DO NOT REPLY BY MAIL.]
> > IMHO the quality of a protocol specification can be determined from how > many questions people ask about it ?., the fewer the questions the less > ambiguous the specification is. You only have to look in these forums to > see the number and variety of problems. If you can write a spec, send it > to a developer in Australia and he/she can decode your data without > needing to contact you for clarification, then the specification is very > high quality. > One of David's main goals prompting him to write the document that became the 1.1 spec was to remove the ambiguity that he saw in the 1.0 days. A tutorial was intentionally left outside the core document (and has yet to materialize). If the spec is ambiguous by e.g. leaving out details or using language that is open to interpretation, that is a problem that should be addressed with an update to the document. Let's distinguish between the document being a non-ambiguous specification or not (can someone in Australia get an implementation right with only the specification document available) and the need for a tutorial and/or a reference implementation that would make life much easier for implementors. I'm not saying the latter is not important. [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
