Imported from previous forum
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
The current release candidate 2 for draft 1 of the FIXML Schema does not use container elements for repeating groups. For instance, when multiple parties are involved in a message - they are included one after another without an outside container:
<Order …>
<Pty ID=1 …/>
<Pty ID=2 …/>
<Pty ID=ABC …/>
<Instrmt …/>
… other order elements here
</Order>
This is a change from FIX 4.3 and previous versions of the FIXML specification (note - this change was introduced in FIX 4.4 DTD version).
The question was raised during the WG conference call on 9/24 regarding the value in creating container elements to contain repeated elements, such as:
<Order …>
<Parties>
<Pty ID=1 …/>
<Pty ID=0427 …/>
<Pty ID=ABC …/>
<Parties>
<Instrmt …/>
… other order elements here
</Order>
There will be a meeting on 9/29 8AM ET to further discuss this topic - please post comments and observations against this discussion item.
I think the “container elements” (the latter example) facilitates Object-to-XML mapping. i.e. I would probably have an object (in a programming language) which represents the collection of Parties and map (and re-use that mapping) the container element to/from the Object which contains the collection. It also facilitates a cleaner mapping to the spec’s “component blocks” concept.
A downside would be increase in message size.
> The current release candidate 2 for draft 1 of the FIXML Schema does not use container elements for repeating groups. For instance, when multiple parties are involved in a message - they are included one after another without an outside container:
>
> <Order …>
> <Pty ID=1 …/>
> <Pty ID=2 …/>
> <Pty ID=ABC …/>
>
> <Instrmt …/>
> … other order elements here
> </Order>
>
> This is a change from FIX 4.3 and previous versions of the FIXML specification (note - this change was introduced in FIX 4.4 DTD version).
>
> The question was raised during the WG conference call on 9/24 regarding the value in creating container elements to contain repeated elements, such as:
>
> <Order …>
> <Parties>
> <Pty ID=1 …/>
> <Pty ID=0427 …/>
> <Pty ID=ABC …/>
> <Parties>
>
> <Instrmt …/>
> … other order elements here
> </Order>
>
> There will be a meeting on 9/29 8AM ET to further discuss this topic - please post comments and observations against this discussion item.
>
>
>
We have no strong views either way on this, but here are a few
(contradictory) points:
- The proposal goes against the 4.4 DTD spec! The container elements were
found to not add significant value but add significant space. - It is quite common for a repeating group to only contain a single entry.
- We disagree that container elements greatly facilitate Object-to-XML
mapping. We have no problem moving between XML based on the current 4.4 DTD
representations and object representations. - Re-introducing container elements would simplify viewing documents - most
XML GUI tools allow you to collapse elements and this would be very useful
for messages such as those containing long lists of allocations or the legs
in a long running swap.
> I think the “container elements” (the latter example) facilitates Object-to-XML mapping. i.e. I would probably have an object (in a programming language) which represents the collection of Parties and map (and re-use that mapping) the container element to/from the Object which contains the collection. It also facilitates a cleaner mapping to the spec’s “component blocks” concept.
>
> A downside would be increase in message size.
>
>
> > The current release candidate 2 for draft 1 of the FIXML Schema does not use container elements for repeating groups. For instance, when multiple parties are involved in a message - they are included one after another without an outside container:
> >
> > <Order …>
> > <Pty ID=1 …/>
> > <Pty ID=2 …/>
> > <Pty ID=ABC …/>
> >
> > <Instrmt …/>
> > … other order elements here
> > </Order>
> >
> > This is a change from FIX 4.3 and previous versions of the FIXML specification (note - this change was introduced in FIX 4.4 DTD version).
> >
> > The question was raised during the WG conference call on 9/24 regarding the value in creating container elements to contain repeated elements, such as:
> >
> > <Order …>
> > <Parties>
> > <Pty ID=1 …/>
> > <Pty ID=0427 …/>
> > <Pty ID=ABC …/>
> > <Parties>
> >
> > <Instrmt …/>
> > … other order elements here
> > </Order>
> >
> > There will be a meeting on 9/29 8AM ET to further discuss this topic - please post comments and observations against this discussion item.
> >
> >
> >
>
[ original email was from Steve Wilkinson - steve.wilkinson@solutionforge.com ]
It would be helpful to have a view on the likely extent of the increase in message size. If we are talking about less than 1-2% (as I suspect we are for most typical messages), I would like to make the case for maintaining the container element as this would be consistent with the way I believe most people are using FIXML on previous versions. For example, I know for a fact that the London Stock Exchange FIXML implementation will be broken if container elements are removed.
> I think the “container elements” (the latter example) facilitates Object-to-XML mapping. i.e. I would probably have an object (in a programming language) which represents the collection of Parties and map (and re-use that mapping) the container element to/from the Object which contains the collection. It also facilitates a cleaner mapping to the spec’s “component blocks” concept.
>
> A downside would be increase in message size.
>
>
> > The current release candidate 2 for draft 1 of the FIXML Schema does not use container elements for repeating groups. For instance, when multiple parties are involved in a message - they are included one after another without an outside container:
> >
> > <Order …>
> > <Pty ID=1 …/>
> > <Pty ID=2 …/>
> > <Pty ID=ABC …/>
> >
> > <Instrmt …/>
> > … other order elements here
> > </Order>
> >
> > This is a change from FIX 4.3 and previous versions of the FIXML specification (note - this change was introduced in FIX 4.4 DTD version).
> >
> > The question was raised during the WG conference call on 9/24 regarding the value in creating container elements to contain repeated elements, such as:
> >
> > <Order …>
> > <Parties>
> > <Pty ID=1 …/>
> > <Pty ID=0427 …/>
> > <Pty ID=ABC …/>
> > <Parties>
> >
> > <Instrmt …/>
> > … other order elements here
> > </Order>
> >
> > There will be a meeting on 9/29 8AM ET to further discuss this topic - please post comments and observations against this discussion item.
> >
> >
> >
>
From what I can gather looking at the draft release, it doesn’t seem to matter whether we use a container element or not for repeating groups. Correct me if I’m wrong, it appears that all the related information to a party will be grouped together regardless of a container element, for example (sorry for not using the actual FIXML Schema tag names):
<Order …>
<PartyID=SALB, PartyIDSource=C, PartyRole=1>
<PartyID=FMR, PartyIDSource=C, PartyRole=3>
(other stuff for order)
</Order>
The value would be in readability of the file, so the above might look like this:
<Order …>
<Parties>
<PartyID=SALB, PartyIDSource=C, PartyRole=1>
<PartyID=FMR, PartyIDSource=C, PartyRole=3>
</Parties>
(other stuff for order)
</Order>
Are there any other pros or cons for the technical value of container elements (besides length of file)?
> The current release candidate 2 for draft 1 of the FIXML Schema does not use container elements for repeating groups. For instance, when multiple parties are involved in a message - they are included one after another without an outside container:
>
> <Order …>
> <Pty ID=1 …/>
> <Pty ID=2 …/>
> <Pty ID=ABC …/>
>
> <Instrmt …/>
> … other order elements here
> </Order>
>
> This is a change from FIX 4.3 and previous versions of the FIXML specification (note - this change was introduced in FIX 4.4 DTD version).
>
> The question was raised during the WG conference call on 9/24 regarding the value in creating container elements to contain repeated elements, such as:
>
> <Order …>
> <Parties>
> <Pty ID=1 …/>
> <Pty ID=0427 …/>
> <Pty ID=ABC …/>
> <Parties>
>
> <Instrmt …/>
> … other order elements here
> </Order>
>
> There will be a meeting on 9/29 8AM ET to further discuss this topic - please post comments and observations against this discussion item.
>
>
>
[ original email was from Robert Stowsky - rstowsky@brookpath.com ]
FpML currently does not use containers. Within an FpML tradeHeader each party is identified by a partyReference element within a separate partyTradeIdentifier element.
<tradeHeader>
<partyTradeIdentifier>
<partyReference href="CHASE"/>
<tradeId tradeIdScheme="http://www.chase.com/swaps/trade-id">TW9235</tradeId>
</partyTradeIdentifier>
<partyTradeIdentifier>
<partyReference href="BARCLAYS"/>
<tradeId tradeIdScheme="http://www.barclays.com/swaps/trade-id">
SW2000</tradeId>
</partyTradeIdentifier>
<tradeDate>1994-12-12</tradeDate>
</tradeHeader>
> The current release candidate 2 for draft 1 of the FIXML Schema does not use container elements for repeating groups. For instance, when multiple parties are involved in a message - they are included one after another without an outside container:
>
> <Order …>
> <Pty ID=1 …/>
> <Pty ID=2 …/>
> <Pty ID=ABC …/>
>
> <Instrmt …/>
> … other order elements here
> </Order>
>
> This is a change from FIX 4.3 and previous versions of the FIXML specification (note - this change was introduced in FIX 4.4 DTD version).
>
> The question was raised during the WG conference call on 9/24 regarding the value in creating container elements to contain repeated elements, such as:
>
> <Order …>
> <Parties>
> <Pty ID=1 …/>
> <Pty ID=0427 …/>
> <Pty ID=ABC …/>
> <Parties>
>
> <Instrmt …/>
> … other order elements here
> </Order>
>
> There will be a meeting on 9/29 8AM ET to further discuss this topic - please post comments and observations against this discussion item.
>
>
>