Imported from previous forum
[ original email was from Robert Woodmansey - rjw@btobits.com ]
We believe there may be a minor typographical issue with the 4.4 spec.
It seems that there are too many cardinality signs applied for repeating group representations in the FIXML 4.4 DTD and this is a typographical error resulting in a logical one.
Short (abridged)version
Where possible
{a, a, a}
renders
{a} {a} {a}
redundant
For example we have <AllocInstrctn> element.
…
<AllocInstrctn>
…
</AllocInstrctn>
…
According to the dtd we can have:
<AllocInstrctn>
<OrdAllocGrp>
…
</OrdAllocGrp>
<OrdAllocGrp>
…
</OrdAllocGrp>
…
</AllocInstrctn>
(it means that the cardinality of OrdAllocGrp is from 0 to infinity)
Each <OrdAllocGrp> can have the following element group (ClOrdID?, OrdID?, ScndOrdID?, ScndClOrdID?, ListID?, NstPtys2?, OrdQty?, OrdAvgPx?, OrdBkngQty? %OrdAllocGrpCustom) repeated from 1 to infinity times
We could have only 1 <OrdAllocGrp> element with its content repeated as many times as we need !From the parsing point of view processing 1 <OrdAllocGrp> element easier and quicker !
Longer example
In the following example it is defined *(from 0 to infinity) cardinality for OrdAllocGrp element in the AllocInstrctn element definition and +(from 1 to infinity) cardinality for content of the OrdAllocGrp
element:
<!ENTITY % AllocInstrctnCustom “” >
<!ENTITY % AllocInstrctnContent “AllocID, AllocTransTyp, AllocTyp, ScndAllocID?, RefAllocID?, AllocCancRplcRsn?, AllocIntermedReqTyp?, AllocLinkID?, AllocLinkTyp?, BkngRefID?, AllocNoOrdsTyp, OrdAllocGrp*, ExecAllocGrp*, PrevlyRpted?, ReversalInd?, MtchTyp?, Side, Instrmt, InstrmtExtension?, FinancingDetails?, UndInstrmtGrp*, InstrmtLegGrp*, Qty, QtyTyp?, LastMkt?, TrdOrigntnDt?, TrdgSessID?, TrdgSessSubID?, PxTyp?, AvgPx, AvgParPx?, SpreadOrBnchmkCrvData?, Ccy?, AvgPxPrcsn?, Ptys?, TrdDt, TransactTm?, SettlTyp?, SettlDt?, BkngTyp?, GrossTrdAmt?, Concession?, TotTakedown?, NetMny?, PosEfct?, AutoAcceptInd?, Text?, EncTextLen?, EncText?, NumDaysInt?, AcrdIntRt?, AcrdIntAmt?, TotAcrdIntAmt?, IntAtMat?, EndAcrdIntAmt?, StartCsh?, EndCsh?, LegalCnfm?, Stips?, YldData?, TotNoAllocs?, LastFragment?, AllocGrp* %AllocInstrctnCustom;” > <!ELEMENT AllocInstrctn (%AllocInstrctnContent;)> <!ATTLIST AllocInstrctn
FIXMsgType_ENUM CDATA #FIXED "J"
Category CDATA #FIXED "Allocation"
FIXSpecVolume CDATA #FIXED 'Volume5’
FullName CDATA #FIXED "AllocationInstruction"
ComponentType CDATA #FIXED “Message” >
<!ENTITY % OrdAllocGrpCustom “” >
<!ENTITY % OrdAllocGrpContent “ClOrdID?, OrdID?, ScndOrdID?, ScndClOrdID?, ListID?, NstPtys2?, OrdQty?, OrdAvgPx?, OrdBkngQty? %OrdAllocGrpCustom;” > <!ELEMENT OrdAllocGrp (%OrdAllocGrpContent;)+> <!ATTLIST OrdAllocGrp
NumInGrp_FIELD CDATA #FIXED 'NoOrds’
FIXTag CDATA #FIXED '73’
ComponentType CDATA #FIXED 'BlockRepeating’
Category CDATA #FIXED ‘Allocation’ >
It means that the following FIXML can be succesfully validated as an XML document but it is hard to determine repeating group instances (start fields of group, count of group instances etc.)
<AllocInstrctn>
<!-- skipped fields -->
<OrdAllocGrp>
<ClOrdID></ClOrdID>
<OrdID></OrdID>
<OrdID></OrdID>
<ClOrdID></ClOrdID>
<ScndOrdID></ScndOrdID>
</OrdAllocGrp>
<OrdAllocGrp>
<ScndOrdID></ScndOrdID>
<ScndOrdID></ScndOrdID>
<ClOrdID></ClOrdID>
</OrdAllocGrp>
<!-- skipped fields -->
</AllocInstrctn>
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
This is an errata item in the FIX 4.4 DTD. We will planning on addressing this with an errata in the near future.
> We believe there may be a minor typographical issue with the 4.4 spec.
>
> It seems that there are too many cardinality signs applied for repeating group representations in the FIXML 4.4 DTD and this is a typographical error resulting in a logical one.
>
> Short (abridged)version
>
> Where possible
> {a, a, a}
> renders
> {a} {a} {a}
> redundant
>
> For example we have <AllocInstrctn> element.
>
> …
> <AllocInstrctn>
> …
> </AllocInstrctn>
> …
>
> According to the dtd we can have:
> <AllocInstrctn>
> <OrdAllocGrp>
> …
> </OrdAllocGrp>
> <OrdAllocGrp>
> …
> </OrdAllocGrp>
> …
> </AllocInstrctn>
> (it means that the cardinality of OrdAllocGrp is from 0 to infinity)
>
> Each <OrdAllocGrp> can have the following element group (ClOrdID?, OrdID?, ScndOrdID?, ScndClOrdID?, ListID?, NstPtys2?, OrdQty?, OrdAvgPx?, OrdBkngQty? %OrdAllocGrpCustom) repeated from 1 to infinity times
>
>
>
> We could have only 1 <OrdAllocGrp> element with its content repeated as many times as we need !From the parsing point of view processing 1 <OrdAllocGrp> element easier and quicker !
>
>
> Longer example
>
> In the following example it is defined (from 0 to infinity) cardinality for OrdAllocGrp element in the AllocInstrctn element definition and +(from 1 to infinity) cardinality for content of the OrdAllocGrp
> element:
>
> <!ENTITY % AllocInstrctnCustom “” >
> <!ENTITY % AllocInstrctnContent "AllocID, AllocTransTyp, AllocTyp, ScndAllocID?, RefAllocID?, AllocCancRplcRsn?, AllocIntermedReqTyp?, AllocLinkID?, AllocLinkTyp?, BkngRefID?, AllocNoOrdsTyp, OrdAllocGrp, ExecAllocGrp*, PrevlyRpted?, ReversalInd?, MtchTyp?, Side, Instrmt, InstrmtExtension?, FinancingDetails?, UndInstrmtGrp*, InstrmtLegGrp*, Qty, QtyTyp?, LastMkt?, TrdOrigntnDt?, TrdgSessID?, TrdgSessSubID?, PxTyp?, AvgPx, AvgParPx?, SpreadOrBnchmkCrvData?, Ccy?, AvgPxPrcsn?, Ptys?, TrdDt, TransactTm?, SettlTyp?, SettlDt?, BkngTyp?, GrossTrdAmt?, Concession?, TotTakedown?, NetMny?, PosEfct?, AutoAcceptInd?, Text?, EncTextLen?, EncText?, NumDaysInt?, AcrdIntRt?, AcrdIntAmt?, TotAcrdIntAmt?, IntAtMat?, EndAcrdIntAmt?, StartCsh?, EndCsh?, LegalCnfm?, Stips?, YldData?, TotNoAllocs?, LastFragment?, AllocGrp* %AllocInstrctnCustom;" > <!ELEMENT AllocInstrctn (%AllocInstrctnContent;)> <!ATTLIST AllocInstrctn
> FIXMsgType_ENUM CDATA #FIXED “J”
> Category CDATA #FIXED “Allocation”
> FIXSpecVolume CDATA #FIXED ‘Volume5’
> FullName CDATA #FIXED “AllocationInstruction”
> ComponentType CDATA #FIXED “Message” >
>
> <!ENTITY % OrdAllocGrpCustom “” >
> <!ENTITY % OrdAllocGrpContent “ClOrdID?, OrdID?, ScndOrdID?, ScndClOrdID?, ListID?, NstPtys2?, OrdQty?, OrdAvgPx?, OrdBkngQty? %OrdAllocGrpCustom;” > <!ELEMENT OrdAllocGrp (%OrdAllocGrpContent;)+> <!ATTLIST OrdAllocGrp
> NumInGrp_FIELD CDATA #FIXED ‘NoOrds’
> FIXTag CDATA #FIXED ‘73’
> ComponentType CDATA #FIXED ‘BlockRepeating’
> Category CDATA #FIXED ‘Allocation’ >
>
> It means that the following FIXML can be succesfully validated as an XML document but it is hard to determine repeating group instances (start fields of group, count of group instances etc.)
>
> <AllocInstrctn>
> <!-- skipped fields -->
> <OrdAllocGrp>
> <ClOrdID></ClOrdID>
> <OrdID></OrdID>
> <OrdID></OrdID>
> <ClOrdID></ClOrdID>
> <ScndOrdID></ScndOrdID>
> </OrdAllocGrp>
> <OrdAllocGrp>
> <ScndOrdID></ScndOrdID>
> <ScndOrdID></ScndOrdID>
> <ClOrdID></ClOrdID>
> </OrdAllocGrp>
> <!-- skipped fields -->
> </AllocInstrctn>
>
>
Thanks Jim, you did not actually say how you would be addressing this! Has this been decided upon yet?
I would have thought that the best solution (and probably what was intended) is to remove the "+" from the contents of block repeating fields so that each block of a block repeating component was in a separate element. e.g. OrdAllocGrp would be defined like this:
<!ELEMENT OrdAllocGrp (%OrdAllocGrpContent;)>
instead of this:
<!ELEMENT OrdAllocGrp (%OrdAllocGrpContent;)+>
Is this correct?
> This is an errata item in the FIX 4.4 DTD. We will planning on addressing this with an errata in the near future.
>
> > We believe there may be a minor typographical issue with the 4.4 spec.
> >
> > It seems that there are too many cardinality signs applied for repeating group representations in the FIXML 4.4 DTD and this is a typographical error resulting in a logical one.
> >
> > Short (abridged)version
> >
> > Where possible
> > {a, a, a}
> > renders
> > {a} {a} {a}
> > redundant
> >
> > For example we have <AllocInstrctn> element.
> >
> > …
> > <AllocInstrctn>
> > …
> > </AllocInstrctn>
> > …
> >
> > According to the dtd we can have:
> > <AllocInstrctn>
> > <OrdAllocGrp>
> > …
> > </OrdAllocGrp>
> > <OrdAllocGrp>
> > …
> > </OrdAllocGrp>
> > …
> > </AllocInstrctn>
> > (it means that the cardinality of OrdAllocGrp is from 0 to infinity)
> >
> > Each <OrdAllocGrp> can have the following element group (ClOrdID?, OrdID?, ScndOrdID?, ScndClOrdID?, ListID?, NstPtys2?, OrdQty?, OrdAvgPx?, OrdBkngQty? %OrdAllocGrpCustom) repeated from 1 to infinity times
> >
> >
> >
> > We could have only 1 <OrdAllocGrp> element with its content repeated as many times as we need !From the parsing point of view processing 1 <OrdAllocGrp> element easier and quicker !
> >
> >
> > Longer example
> >
> > In the following example it is defined (from 0 to infinity) cardinality for OrdAllocGrp element in the AllocInstrctn element definition and +(from 1 to infinity) cardinality for content of the OrdAllocGrp
> > element:
> >
> > <!ENTITY % AllocInstrctnCustom “” >
> > <!ENTITY % AllocInstrctnContent "AllocID, AllocTransTyp, AllocTyp, ScndAllocID?, RefAllocID?, AllocCancRplcRsn?, AllocIntermedReqTyp?, AllocLinkID?, AllocLinkTyp?, BkngRefID?, AllocNoOrdsTyp, OrdAllocGrp, ExecAllocGrp*, PrevlyRpted?, ReversalInd?, MtchTyp?, Side, Instrmt, InstrmtExtension?, FinancingDetails?, UndInstrmtGrp*, InstrmtLegGrp*, Qty, QtyTyp?, LastMkt?, TrdOrigntnDt?, TrdgSessID?, TrdgSessSubID?, PxTyp?, AvgPx, AvgParPx?, SpreadOrBnchmkCrvData?, Ccy?, AvgPxPrcsn?, Ptys?, TrdDt, TransactTm?, SettlTyp?, SettlDt?, BkngTyp?, GrossTrdAmt?, Concession?, TotTakedown?, NetMny?, PosEfct?, AutoAcceptInd?, Text?, EncTextLen?, EncText?, NumDaysInt?, AcrdIntRt?, AcrdIntAmt?, TotAcrdIntAmt?, IntAtMat?, EndAcrdIntAmt?, StartCsh?, EndCsh?, LegalCnfm?, Stips?, YldData?, TotNoAllocs?, LastFragment?, AllocGrp* %AllocInstrctnCustom;" > <!ELEMENT AllocInstrctn (%AllocInstrctnContent;)> <!ATTLIST AllocInstrctn
> > FIXMsgType_ENUM CDATA #FIXED “J”
> > Category CDATA #FIXED “Allocation”
> > FIXSpecVolume CDATA #FIXED ‘Volume5’
> > FullName CDATA #FIXED “AllocationInstruction”
> > ComponentType CDATA #FIXED “Message” >
> >
> > <!ENTITY % OrdAllocGrpCustom “” >
> > <!ENTITY % OrdAllocGrpContent “ClOrdID?, OrdID?, ScndOrdID?, ScndClOrdID?, ListID?, NstPtys2?, OrdQty?, OrdAvgPx?, OrdBkngQty? %OrdAllocGrpCustom;” > <!ELEMENT OrdAllocGrp (%OrdAllocGrpContent;)+> <!ATTLIST OrdAllocGrp
> > NumInGrp_FIELD CDATA #FIXED ‘NoOrds’
> > FIXTag CDATA #FIXED ‘73’
> > ComponentType CDATA #FIXED ‘BlockRepeating’
> > Category CDATA #FIXED ‘Allocation’ >
> >
> > It means that the following FIXML can be succesfully validated as an XML document but it is hard to determine repeating group instances (start fields of group, count of group instances etc.)
> >
> > <AllocInstrctn>
> > <!-- skipped fields -->
> > <OrdAllocGrp>
> > <ClOrdID></ClOrdID>
> > <OrdID></OrdID>
> > <OrdID></OrdID>
> > <ClOrdID></ClOrdID>
> > <ScndOrdID></ScndOrdID>
> > </OrdAllocGrp>
> > <OrdAllocGrp>
> > <ScndOrdID></ScndOrdID>
> > <ScndOrdID></ScndOrdID>
> > <ClOrdID></ClOrdID>
> > </OrdAllocGrp>
> > <!-- skipped fields -->
> > </AllocInstrctn>
> >
> >
>
Yes, the "+" will be removed as per your example.
> Thanks Jim, you did not actually say how you would be addressing this! Has this been decided upon yet?
>
> I would have thought that the best solution (and probably what was intended) is to remove the “+” from the contents of block repeating fields so that each block of a block repeating component was in a separate element. e.g. OrdAllocGrp would be defined like this:
>
> <!ELEMENT OrdAllocGrp (%OrdAllocGrpContent;)>
>
> instead of this:
>
> <!ELEMENT OrdAllocGrp (%OrdAllocGrpContent;)+>
>
> Is this correct?
>
> > This is an errata item in the FIX 4.4 DTD. We will planning on addressing this with an errata in the near future.
> >
> > > We believe there may be a minor typographical issue with the 4.4 spec.
> > >
> > > It seems that there are too many cardinality signs applied for repeating group representations in the FIXML 4.4 DTD and this is a typographical error resulting in a logical one.
> > >
> > > Short (abridged)version
> > >
> > > Where possible
> > > {a, a, a}
> > > renders
> > > {a} {a} {a}
> > > redundant
> > >
> > > For example we have <AllocInstrctn> element.
> > >
> > > …
> > > <AllocInstrctn>
> > > …
> > > </AllocInstrctn>
> > > …
> > >
> > > According to the dtd we can have:
> > > <AllocInstrctn>
> > > <OrdAllocGrp>
> > > …
> > > </OrdAllocGrp>
> > > <OrdAllocGrp>
> > > …
> > > </OrdAllocGrp>
> > > …
> > > </AllocInstrctn>
> > > (it means that the cardinality of OrdAllocGrp is from 0 to infinity)
> > >
> > > Each <OrdAllocGrp> can have the following element group (ClOrdID?, OrdID?, ScndOrdID?, ScndClOrdID?, ListID?, NstPtys2?, OrdQty?, OrdAvgPx?, OrdBkngQty? %OrdAllocGrpCustom) repeated from 1 to infinity times
> > >
> > >
> > >
> > > We could have only 1 <OrdAllocGrp> element with its content repeated as many times as we need !From the parsing point of view processing 1 <OrdAllocGrp> element easier and quicker !
> > >
> > >
> > > Longer example
> > >
> > > In the following example it is defined (from 0 to infinity) cardinality for OrdAllocGrp element in the AllocInstrctn element definition and +(from 1 to infinity) cardinality for content of the OrdAllocGrp
> > > element:
> > >
> > > <!ENTITY % AllocInstrctnCustom “” >
> > > <!ENTITY % AllocInstrctnContent "AllocID, AllocTransTyp, AllocTyp, ScndAllocID?, RefAllocID?, AllocCancRplcRsn?, AllocIntermedReqTyp?, AllocLinkID?, AllocLinkTyp?, BkngRefID?, AllocNoOrdsTyp, OrdAllocGrp, ExecAllocGrp*, PrevlyRpted?, ReversalInd?, MtchTyp?, Side, Instrmt, InstrmtExtension?, FinancingDetails?, UndInstrmtGrp*, InstrmtLegGrp*, Qty, QtyTyp?, LastMkt?, TrdOrigntnDt?, TrdgSessID?, TrdgSessSubID?, PxTyp?, AvgPx, AvgParPx?, SpreadOrBnchmkCrvData?, Ccy?, AvgPxPrcsn?, Ptys?, TrdDt, TransactTm?, SettlTyp?, SettlDt?, BkngTyp?, GrossTrdAmt?, Concession?, TotTakedown?, NetMny?, PosEfct?, AutoAcceptInd?, Text?, EncTextLen?, EncText?, NumDaysInt?, AcrdIntRt?, AcrdIntAmt?, TotAcrdIntAmt?, IntAtMat?, EndAcrdIntAmt?, StartCsh?, EndCsh?, LegalCnfm?, Stips?, YldData?, TotNoAllocs?, LastFragment?, AllocGrp* %AllocInstrctnCustom;" > <!ELEMENT AllocInstrctn (%AllocInstrctnContent;)> <!ATTLIST AllocInstrctn
> > > FIXMsgType_ENUM CDATA #FIXED “J”
> > > Category CDATA #FIXED “Allocation”
> > > FIXSpecVolume CDATA #FIXED ‘Volume5’
> > > FullName CDATA #FIXED “AllocationInstruction”
> > > ComponentType CDATA #FIXED “Message” >
> > >
> > > <!ENTITY % OrdAllocGrpCustom “” >
> > > <!ENTITY % OrdAllocGrpContent “ClOrdID?, OrdID?, ScndOrdID?, ScndClOrdID?, ListID?, NstPtys2?, OrdQty?, OrdAvgPx?, OrdBkngQty? %OrdAllocGrpCustom;” > <!ELEMENT OrdAllocGrp (%OrdAllocGrpContent;)+> <!ATTLIST OrdAllocGrp
> > > NumInGrp_FIELD CDATA #FIXED ‘NoOrds’
> > > FIXTag CDATA #FIXED ‘73’
> > > ComponentType CDATA #FIXED ‘BlockRepeating’
> > > Category CDATA #FIXED ‘Allocation’ >
> > >
> > > It means that the following FIXML can be succesfully validated as an XML document but it is hard to determine repeating group instances (start fields of group, count of group instances etc.)
> > >
> > > <AllocInstrctn>
> > > <!-- skipped fields -->
> > > <OrdAllocGrp>
> > > <ClOrdID></ClOrdID>
> > > <OrdID></OrdID>
> > > <OrdID></OrdID>
> > > <ClOrdID></ClOrdID>
> > > <ScndOrdID></ScndOrdID>
> > > </OrdAllocGrp>
> > > <OrdAllocGrp>
> > > <ScndOrdID></ScndOrdID>
> > > <ScndOrdID></ScndOrdID>
> > > <ClOrdID></ClOrdID>
> > > </OrdAllocGrp>
> > > <!-- skipped fields -->
> > > </AllocInstrctn>
> > >
> > >
> >
>