quickfix-developers

[Quickfix-developers] enum values for Product field 460

[John M. <jo...@tr...>]

QF's FIX44.xml file lists only 9 enumerated values for the Product field
(tag 460). However, the 4.4 spec and FIXimate lists 13. The differences
are the following values:
10 = MORTGAGE
11 = MUNICIPAL
12 = OTHER
13 = FINANCING

Have these values been deprecated in the 4.4 spec or is QF's FIX44.xml
file not up-to-date?

Thanks in advance, John Messmer

[Quickfix-developers] Discrepancies in FIX44.xml?

[James W. <wi...@wi...>]

 Folks,

   I'm working with the FIX44.xml specification document off the
QuickFIX site and I've spotted what seem like discrepancies between
it and the FIX4.4 spec at fixprotocol.org.  The MDEntryRefID "group"
under MarketDataIncrementalRefresh doesn't appear to jibe with what
is defined in the fixprotocol.org FIXIimate documentation.  Is this
a "group" that isn't a repeating group, but just an organizational
convenience?  There is no "NoMDEntryRefID" defined in FIXimate to
indicate that MDEntryRefID is a repeating group.  FIXimate defines
it as a string field.  What's up, here?

   Secondly, the FIX header clearly specifies a field "NoHops" to
indicate the number of "HopCompID" groups, but FIX44.xml has:
...
    <field name="LastMsgSeqNumProcessed" required="N" />
    <group name="HopCompID" required="N">
      <field name="HopCompID" required="N" />
      <field name="HopSendingTime" required="N" />
      <field name="HopRefID" required="N" />
    </group>
</header>
...
   A typo?  Or is this deliberate?  Shouldn't it be instead:
...
    <field name="LastMsgSeqNumProcessed" required="N" />
    <group name="NoHops" required="N">
      <field name="HopCompID" required="N" />
      <field name="HopSendingTime" required="N" />
      <field name="HopRefID" required="N" />
    </group>
</header>
...

   Finally, the "News" message type defines the group number field
for "Text" as "NoLinesOfText" but FIX44.xml contains:
...
      <group name="LinesOfText" required="Y">
        <field name="Text" required="Y" />
        <field name="EncodedTextLen" required="N" />
        <field name="EncodedText" required="N" />
      </group>
...
   So, shouldn't it be:
...
      <group name="NoLinesOfText" required="Y">
        <field name="Text" required="Y" />
        <field name="EncodedTextLen" required="N" />
        <field name="EncodedText" required="N" />
      </group>
...

   That said, I've gotten an enormous amount of benefit from these
spec files and want to send profuse thanks to whomever built them
and then made them available!

regards,
Jim Wiggs

Re: [Quickfix-developers] Discrepancies in FIX44.xml?

[Oren M. <or...@qu...>]

The first two are probably issues with the parsing.  Instead of making 
it easier, the FPL has made it much more difficult to create a data 
dictionary.  Back in FIX.4.2 the entire spec was available in one html 
file.  Not ideal but relatively easy to parse.  In the past two 
releases however they have only released the spec as 7 Word documents.  
This makes parsing difficult, particularly since these documents are 
seemingly created by hand and there isn't perfect consistency in how 
things are laid out.  We tried to account for all of the exceptions, 
but some slip by.  So we just try to fix them as they are reported.

As for the LinesOfText, well, Fiximate lists it as NoLinesOfText, while 
the official FIX 4.4 specification document lists it as LinesOfText.  
Since the document is supposed to define the standard, that's what we 
go with (even through NoLinesOfText is what it really should be if you 
go by the naming convention).  A bit worrisome since it appears someone 
is keeping two versions of the spec.  I think it is likely due to a 
transition the FPL is going through.  I'm told that the spec is now 
being kept in an Access database, so hopefully future versions will be 
generated off of this database.

--oren

On Aug 29, 2004, at 3:36 PM, James Wiggs wrote:

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: 
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>  Folks,
>
>    I'm working with the FIX44.xml specification document off the
> QuickFIX site and I've spotted what seem like discrepancies between
> it and the FIX4.4 spec at fixprotocol.org.  The MDEntryRefID "group"
> under MarketDataIncrementalRefresh doesn't appear to jibe with what
> is defined in the fixprotocol.org FIXIimate documentation.  Is this
> a "group" that isn't a repeating group, but just an organizational
> convenience?  There is no "NoMDEntryRefID" defined in FIXimate to
> indicate that MDEntryRefID is a repeating group.  FIXimate defines
> it as a string field.  What's up, here?
>
>    Secondly, the FIX header clearly specifies a field "NoHops" to
> indicate the number of "HopCompID" groups, but FIX44.xml has:
> ...
>     <field name="LastMsgSeqNumProcessed" required="N" />
>     <group name="HopCompID" required="N">
>       <field name="HopCompID" required="N" />
>       <field name="HopSendingTime" required="N" />
>       <field name="HopRefID" required="N" />
>     </group>
> </header>
> ...
>    A typo?  Or is this deliberate?  Shouldn't it be instead:
> ...
>     <field name="LastMsgSeqNumProcessed" required="N" />
>     <group name="NoHops" required="N">
>       <field name="HopCompID" required="N" />
>       <field name="HopSendingTime" required="N" />
>       <field name="HopRefID" required="N" />
>     </group>
> </header>
> ...
>
>    Finally, the "News" message type defines the group number field
> for "Text" as "NoLinesOfText" but FIX44.xml contains:
> ...
>       <group name="LinesOfText" required="Y">
>         <field name="Text" required="Y" />
>         <field name="EncodedTextLen" required="N" />
>         <field name="EncodedText" required="N" />
>       </group>
> ...
>    So, shouldn't it be:
> ...
>       <group name="NoLinesOfText" required="Y">
>         <field name="Text" required="Y" />
>         <field name="EncodedTextLen" required="N" />
>         <field name="EncodedText" required="N" />
>       </group>
> ...
>
>    That said, I've gotten an enormous amount of benefit from these
> spec files and want to send profuse thanks to whomever built them
> and then made them available!
>
> regards,
> Jim Wiggs
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] Discrepancies in FIX44.xml?

[Caleb E. <cal...@gm...>]

On Sun, 29 Aug 2004 22:51:24 -0500, Oren Miller <or...@qu...> wrote:

> I'm told that the spec is now being kept in an Access database

     Wow.  Thats scary.

-- 
Caleb Epstein
cal...@gm...

Re: [Quickfix-developers] Discrepancies in FIX44.xml?

[John M. <jo...@tr...>]

You're right... that's very scary. Has anyone suggested that the FIX
repository be maintained in a non-MS based d-base? I've noticed the
strong MS base among the FIX folks. We non-MS folks need to be heard
among the FIX community.

IMHO, The very idea of the official FIX spec being distributed in a Word
doc versus an XML file format is insane! So what does that tell us?

John

On Mon, 2004-08-30 at 07:59, Caleb Epstein wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> On Sun, 29 Aug 2004 22:51:24 -0500, Oren Miller <or...@qu...> wrote:
> 
> > I'm told that the spec is now being kept in an Access database
> 
>      Wow.  Thats scary.

Re: [Quickfix-developers] Discrepancies in FIX44.xml?

[Oren M. <or...@qu...>]

It's something that has been discussed, and for a short time there was 
even some discussion of using some variation of the QuickFIX xml 
format, but I think they wanted to go their own way.  Frankly I could 
care less if they put it together with an Access database, as long as 
they generate XML files.  In any case, I'd be more than happy to donate 
a process that will convert their database into a mysql database.  As 
long as the spec is distributed in a machine readable format, we can do 
with it what we will.

--oren

On Aug 30, 2004, at 8:35 AM, John Messmer wrote:

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: 
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> You're right... that's very scary. Has anyone suggested that the FIX
> repository be maintained in a non-MS based d-base? I've noticed the
> strong MS base among the FIX folks. We non-MS folks need to be heard
> among the FIX community.
>
> IMHO, The very idea of the official FIX spec being distributed in a 
> Word
> doc versus an XML file format is insane! So what does that tell us?
>
> John
>
> On Mon, 2004-08-30 at 07:59, Caleb Epstein wrote:
>> QuickFIX Documentation: 
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX FAQ: 
>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> On Sun, 29 Aug 2004 22:51:24 -0500, Oren Miller 
>> <or...@qu...> wrote:
>>
>>> I'm told that the spec is now being kept in an Access database
>>
>>      Wow.  Thats scary.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>