cardinality errata

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>

Yes, there does seem to be something strange going on here. I cannot see the point having both the "" following OrdAllocGrp and the "+" following (%OrdAllocGrpContent;) either. I suspect that the "" following OrdAllocGrp should be a "?", as this is implicit in the work on the 4.4DTD (removal of redundant containers). i.e. you can have at most one OrdAllocGrp element and the component elements repeat inside it. This is how we have interpreted the 4.4 DTD.

Incidentally, the spec says that ClOrdID is required if NoOrders > 0, so your example is valid according to the DTD, but not according to the spec. The way I read it, the start of each repeating group must begin with a <ClOrdID>.

A little clarification from the experts would be highly desireable here.

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