[QFJ-40] MarketDepth enum status inconsistent Created: 25/Jul/06 Updated: 02/Sep/06 Resolved: 29/Jul/06 |
|
Status: | Closed |
Project: | QuickFIX/J |
Component/s: | Metadata/Specs |
Affects Version/s: | None |
Fix Version/s: | 1.0.2 |
Type: | Bug | Priority: | Default |
Reporter: | Nick Fortescue | Assignee: | Steve Bate |
Resolution: | Fixed | Votes: | 0 |
Labels: | None |
Attachments: | FIX42.xml FIX43.xml FIX44-nospace.xml FIX44.xml |
Description |
1) A very minor inconsistency is that FIX42 and 43 end elements like "/> (without a space) and 44 ends like " /> (with a space). 2) MarketDepth is a funny Field. It is like an enum, in that values for 0 and 1 have names. It is different from an enum in that values >1 are legal, At the moment the 3 relevant FIX xml files are inconsistent. FIX42.xml has the enum in, FIX43.xml has it in, but commented out with an explanatory comment, Possible solutions: 2) I can't find anywhere in the code that breaks if the enums for MarketDepth are there, but I might not be looking in the right place. After all, you would hope enums were validated. Can the enums just be put back in (for 43 and 44)? I'll attached the files with the enums back in, and a comment mentioning the N>1 case if you want to add them back. |
Comments |
Comment by Nick Fortescue [ 25/Jul/06 ] |
A file with some extra space removed before the close of XML elements, so the file is consistent with the FIX42.xml and FIX43.xml files |
Comment by Nick Fortescue [ 25/Jul/06 ] |
The FIX 42,43, and 44 files with the enumerated values for MarketDepth added back in, and a comment added to mention the N>1 case |
Comment by Jörg Thönnes [ 26/Jul/06 ] |
How about having an empty value element: <field ...> which would indicate that other values are possible? Or etc. etc. We should also check native QF whether it works there. |
Comment by Nick Fortescue [ 26/Jul/06 ] |
Those are both good ideas, I think I prefer the <value enum="..."> solution, as it would work for non-integer enums. Another possibility is have a <value constant="0" description ="FULL_BOOK"/> indicating this isn't an enum, it was just a special constant value. However, this fails to encapsulate the knowledge that values <0 are illegal. Checking with native QF is a good idea, we should keep the files the same ideally. |
Comment by Steve Bate [ 26/Jul/06 ] |
I haven't looked since this issue was raised, but the QuickFIX C++ spec files were also inconsistent for this enum. They might have been changed since I looked last so I'll look again when I have some time. |
Comment by Steve Bate [ 26/Jul/06 ] |
It looks like the QuickFIX C++ spec files comment the enums for 4.2-4.4. The only issue I can think of for uncommenting the fields is that it may cause validation to start failing with existing installations. Is the lack of constant generation the only problem with the commented fields? |
Comment by Steve Bate [ 29/Jul/06 ] |
I've decided to comment the enums in all versions. I've updated the 1.0.x branch and the trunk. |