-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Composites reusing other types #12
Comments
Possible solutions:
Either way, it should allow |
Can you provide examples of how it was tested for the specification? |
I understand that this does not work with the current schema; I'm trying to throw out ideas about how to resolve it. I'm open to other proposals. |
Maybe something like |
For reference I see people want to define a common type that is part of a message. This common type can then be passed to methods for getting or putting fields and used across multiple message types. This is a good reason to complex composites, but importantly they need to refer to other common types. For example, common fields in different order type messages can be pulled out and handled by common code otherwise the code must be repeated when no common type exists. |
We would also like to implement the composite features this week before the holidays are upon us. Do you think you can get an answer from the committee soon? |
The A contrived example with the referenced type is Boolean enum:
|
@mjpt777 a block of common fields could be defined as a |
@donmendelson The |
Our choice will be implement as RC3 but this is not really workable for composites to be generally useful or go with some assumptions. We could assume offset and ref gets approved but will not have time to go back and change the reference implementation if a different decision is made. Maybe a good lesson from other standards bodies is not to publish a spec until a working reference implementation has been tried. |
We haven't published a specification yet. We have release candidates. On Mon, Dec 14, 2015 at 11:09 AM, Martin Thompson notifications@github.com
|
@jimnup It's the same. It is published. See RFC :-) Specs need to be verified with implementation as primary input. |
(Depends on offset attribute added for FIXTradingCommunity#11.)
It is a chicken and egg problem. Release Candidates are the deliverables FIX chose to be able to make changes prior to a (Draft) Standard that can only be subject to very minor changes. Engagement within the FIX membership was quite low, hence the decision to move to github with the latest Release Candidates. Without "publishing" it there we cannot get any feedback from the wider community to make changes or enhancements before defining it to be a (Draft) Standard. We should not get hung up on the definition of "publish". Fact of the matter is that changes and enhancements are currently still possible and will be made. At the same time it should not be a moving target, i.e. a decision should be made rather sooner than later to make RC4 the last Release Candidate of V1.0 which can be the basis for the Draft Standard after the public review period of 90 days. The Draft Standard for Version 1.0 will be accompanied by announcements from FIX, much more than any of the Release Candidates, due to the commitment from FIX to move any further changes or enhancements to higher versions, protecting any investments made. Before removing "Draft" FIX wants to see two interoperable implementations, verifying the paper spec. |
@kleihan How does the FIX standards body prove, in a formal way, that two implementations interoperate correctly? For this, other standards implement a TCK (Technology Compatibility Tootkit). I understand the chicken and egg issue and many standards bodies have struggled with it. The one major lesson is that a spec needs to be led by trying to implement. Otherwise specs can become unworkable. Look to the history of the CORBA persistence service to see how this can fail without implementation. The IETF get a lot of this right https://www.ietf.org/about/standards-process.html
Note the first two points are led by technical implementation. This tends to catch many errors and flaws early. |
@mjpt777 I agree that technical implementation is key. I do not think the intention is to formally prove 100% interoperability of all SBE features. It is also a question of effort needed and bandwidth available. FIX is to be fit for purpose, i.e. it will likely be more of a judgement call of experts that show interest. This may not be enough for an IETF standard but it is probably the best we can do right now. The AMQP standard showed interoperability by having prototype implementations from two vendors exchange messages with each other.The same could be done for SBE with pre-defined FIX messages encoded and decoded with different implementations. |
Corrections for #12, example added
If I define a reusable type such as a Boolean enum then how can I reuse that across multiple composites?
The text was updated successfully, but these errors were encountered: