# cardinality issue from B2BITS

**URL:** <https://forum.fixtrading.org/t/cardinality-issue-from-b2bits/6030>\
**Category:** General Q&A\
**Tags:** fixml\_schema, xid\_165241, imported\
**Created:** [September 26, 2003, 3:16pm UTC](https://forum.fixtrading.org/t/cardinality-issue-from-b2bits/6030 "2003-09-26T15:16:00Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\
**Post date:** [September 26, 2003, 3:16pm UTC](https://forum.fixtrading.org/t/cardinality-issue-from-b2bits/6030/1 "2003-09-26T15:16:00Z")

</div>

Imported from previous forum

---

<div class="post-metadata">

**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\
**Post date:** [September 26, 2003, 3:16pm UTC](https://forum.fixtrading.org/t/cardinality-issue-from-b2bits/6030/2 "2003-09-26T15:16:00Z")

</div>

[original email was from Robert Woodmansey - [rjw@btobits.com](mailto: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\>

---

<div class="post-metadata">

**Author:** ![fplpo\_x](https://avatars.discourse-cdn.com/v4/letter/f/7ab992/32.png) [@fplpo\_x](https://forum.fixtrading.org/u/fplpo_x)\
**Post date:** [September 29, 2003, 1:33pm UTC](https://forum.fixtrading.org/t/cardinality-issue-from-b2bits/6030/3 "2003-09-29T13:33:00Z")

</div>

[original email was from Jim Northey - [jnorthey@lasalletech.com](mailto: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\>  
\>  
\>

---

<div class="post-metadata">

**Author:** ![paulmapstone\_x](https://avatars.discourse-cdn.com/v4/letter/p/5f9b8f/32.png) [@paulmapstone\_x](https://forum.fixtrading.org/u/paulmapstone_x)\
**Post date:** [September 30, 2003, 10:25am UTC](https://forum.fixtrading.org/t/cardinality-issue-from-b2bits/6030/4 "2003-09-30T10:25:00Z")

</div>

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\>  
\> \>  
\> \>  
\>

---

<div class="post-metadata">

**Author:** ![scott.atwell](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@scott.atwell](https://forum.fixtrading.org/u/scott.atwell)\
**Post date:** [September 30, 2003, 11:52am UTC](https://forum.fixtrading.org/t/cardinality-issue-from-b2bits/6030/5 "2003-09-30T11:52:00Z")

</div>

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\>  
\> \> \>  
\> \> \>  
\> \>  
\>