Imported from previous forum
My last one, I promise.
Again my motivation here is what the Java class code generation looks like after processing the FIXML schema.
Here is an example of the number of classes it takes to build a header object using the FIXML schema as is and processed by Castor( from www.exolab.org):
// Create and set Sender
Sndr sender = new Sndr();
sender.setID( "GLFIX");
// Create and set Target
Tgt target = new Tgt();
target.setID( "GCC");
target.setSub("GCC");
// Create and set onBehalfOfCompID
OnBhlfOf onBehalfOf = new OnBhlfOf();
onBehalfOf.setID( "SSGMGCC");
onBehalfOf.setSub("SSGMGCC");
// Create required header elements.
BaseHeaderElementsRequired headerEleReqd = new BaseHeaderElementsRequired();
headerEleReqd.setSndr( sender);
headerEleReqd.setTgt( target);
// Create optional header elements.
BaseHeaderElementsOptional headerEleOpt = new BaseHeaderElementsOptional();
headerEleOpt.setOnBhlfOf( onBehalfOf);
// Create and set header.
Hdr header = new Hdr();
header.setBaseHeaderElementsRequired( headerEleReqd);
header.setBaseHeaderElementsOptional( headerEleOpt);
header.setPossDupFlag("N");
header.setSnt(sntDt);
You end up creating SIX objects to put together a header object.
Here is sample code for getting the SenderCompID from this composite of objects:
System.out.println( "SenderCompID: "+ord.getHdr().getBaseHeaderElementsRequired().getSndr().getID());
It takes FOUR function calls to get a Sender ID. Ideally all I would want to do is ord.getHdr().getID(), cutting the number of method calls in half.
If your building or routing thousands of orders/executions then this is going to raise performance concerns.
I like the design of MessageHeader_t, but because of the code generation consequences, I ask that the committee consider that the header be flattened, meaning that attributes be used for most values. More specifically, remove the layers consisting of BaseHeaderElementsX and the layer below consisting of onBhlfOf, DlvrTo, and Hop.
Gerry Capone
Gerry,
This problem stems from the same issue with castor as mentioned in your other email (set minOccurs of ElementsOptional and Custom to 0) to which I had responded. Again, I advise against making the change. It is part of a bigger problem, either we flatten EVERYTHING, or we dont do it at all.
Sik.
Alberta Market Solutions Ltd.
M: +1-403-714-2288
F: +1-403-685-4025
P: +1-403-246-5104
E: sik.ngai@albertasolutions.com
> My last one, I promise.
>
> Again my motivation here is what the Java class code generation looks like after processing the FIXML schema.
>
> Here is an example of the number of classes it takes to build a header object using the FIXML schema as is and processed by Castor( from www.exolab.org):
> ------------------------------
> // Create and set Sender
> Sndr sender = new Sndr();
> sender.setID( "GLFIX");
>
> // Create and set Target
> Tgt target = new Tgt();
> target.setID( "GCC");
> target.setSub("GCC");
>
> // Create and set onBehalfOfCompID
> OnBhlfOf onBehalfOf = new OnBhlfOf();
> onBehalfOf.setID( "SSGMGCC");
> onBehalfOf.setSub("SSGMGCC");
>
> // Create required header elements.
> BaseHeaderElementsRequired headerEleReqd = new BaseHeaderElementsRequired();
> headerEleReqd.setSndr( sender);
> headerEleReqd.setTgt( target);
>
> // Create optional header elements.
> BaseHeaderElementsOptional headerEleOpt = new BaseHeaderElementsOptional();
> headerEleOpt.setOnBhlfOf( onBehalfOf);
>
> // Create and set header.
> Hdr header = new Hdr();
> header.setBaseHeaderElementsRequired( headerEleReqd);
> header.setBaseHeaderElementsOptional( headerEleOpt);
> header.setPossDupFlag("N");
> header.setSnt(sntDt);
> -----------------------------
>
> You end up creating SIX objects to put together a header object.
>
> Here is sample code for getting the SenderCompID from this composite of objects:
> System.out.println( "SenderCompID: "+ord.getHdr().getBaseHeaderElementsRequired().getSndr().getID());
>
>
> It takes FOUR function calls to get a Sender ID. Ideally all I would want to do is ord.getHdr().getID(), cutting the number of method calls in half.
>
> If your building or routing thousands of orders/executions then this is going to raise performance concerns.
>
> I like the design of MessageHeader_t, but because of the code generation consequences, I ask that the committee consider that the header be flattened, meaning that attributes be used for most values. More specifically, remove the layers consisting of BaseHeaderElementsX and the layer below consisting of onBhlfOf, DlvrTo, and Hop.
>
> Gerry Capone
>
Sik,
Take Castor out of the equation again. The fundamental point here is that the header was designed with element within element within element etc…
I agree with your point that changes should not be made to satisfy a particular third party tool. But, it is not about that. Castor just happens to bring some issues to light. Issues that effect a promising and growing technology, "Code Generation". In particular code generation using XML Schema.
This aspect(code generation) of schema design may not of been considered when creating the FIXML 4.4 schema.
I see a parallel here with database schema design and the data modeling concepts of normalization and de-normalization. Normalization is used to put together a well designed schema then reality(a.k.a performance issues) forces de-normalization of the schema so that we can get it to production.
A final thought, I do believe some sort of custom schema processing (as you suggest), most likely with XSLT, by the implementor (me) is a valid counter argument.
Just trying to follow my dream of actaully getting something that works right out of the box for once. 8 )
> Gerry,
>
> This problem stems from the same issue with castor as mentioned in your other email (set minOccurs of ElementsOptional and Custom to 0) to which I had responded. Again, I advise against making the change. It is part of a bigger problem, either we flatten EVERYTHING, or we dont do it at all.
>
> Sik.
> Alberta Market Solutions Ltd.
> M: +1-403-714-2288
> F: +1-403-685-4025
> P: +1-403-246-5104
> E: sik.ngai@albertasolutions.com
>
>
> > My last one, I promise.
> >
> > Again my motivation here is what the Java class code generation looks like after processing the FIXML schema.
> >
> > Here is an example of the number of classes it takes to build a header object using the FIXML schema as is and processed by Castor( from www.exolab.org):
> > ------------------------------
> > // Create and set Sender
> > Sndr sender = new Sndr();
> > sender.setID( "GLFIX");
> >
> > // Create and set Target
> > Tgt target = new Tgt();
> > target.setID( "GCC");
> > target.setSub("GCC");
> >
> > // Create and set onBehalfOfCompID
> > OnBhlfOf onBehalfOf = new OnBhlfOf();
> > onBehalfOf.setID( "SSGMGCC");
> > onBehalfOf.setSub("SSGMGCC");
> >
> > // Create required header elements.
> > BaseHeaderElementsRequired headerEleReqd = new BaseHeaderElementsRequired();
> > headerEleReqd.setSndr( sender);
> > headerEleReqd.setTgt( target);
> >
> > // Create optional header elements.
> > BaseHeaderElementsOptional headerEleOpt = new BaseHeaderElementsOptional();
> > headerEleOpt.setOnBhlfOf( onBehalfOf);
> >
> > // Create and set header.
> > Hdr header = new Hdr();
> > header.setBaseHeaderElementsRequired( headerEleReqd);
> > header.setBaseHeaderElementsOptional( headerEleOpt);
> > header.setPossDupFlag("N");
> > header.setSnt(sntDt);
> > -----------------------------
> >
> > You end up creating SIX objects to put together a header object.
> >
> > Here is sample code for getting the SenderCompID from this composite of objects:
> > System.out.println( "SenderCompID: "+ord.getHdr().getBaseHeaderElementsRequired().getSndr().getID());
> >
> >
> > It takes FOUR function calls to get a Sender ID. Ideally all I would want to do is ord.getHdr().getID(), cutting the number of method calls in half.
> >
> > If your building or routing thousands of orders/executions then this is going to raise performance concerns.
> >
> > I like the design of MessageHeader_t, but because of the code generation consequences, I ask that the committee consider that the header be flattened, meaning that attributes be used for most values. More specifically, remove the layers consisting of BaseHeaderElementsX and the layer below consisting of onBhlfOf, DlvrTo, and Hop.
> >
> > Gerry Capone
> >
>
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
We definitely worked on eliminating extra container elements from the instance documents for FIXML. We added groups and attributeGroups for extensibility only in the schema. We obviously were trying to address extensibility as required by the specification over pure schema size optimization. We also had the constraint of being able to have enough meta data on hand to generate tag=value FIX from FIXML.
Regarding our general approach - we tried to find a reasonable middle ground in our implementation.
It seems to me that the extra nesting in the header is not that useful. Also, it seems like if we can add minOccurs=0 to *elementGroupCustom and *elementGroupOptional (when there are no elements - probably should generalize this to any empty group) this seems to be in keeping with the spirit of what we were trying to accomplish with the schema: straight forward consistent approach for extending the specification, while at the same time make default usage straightforward and easy.
I think flattening to make code generation optimal is outweighed by our extensibility requirements. Flattening the header makes sense to me from a general perspective of a lean instance message. Folks using individual header messages will likely have a transaction throughput requirement they need to meet - anything to make the implementation of FIXML more viable for them is a good thing.
Adding minOccurs=0 to *GroupCustom and *GroupOptional makes sense if it will permit users to ignore CustomGroups if they are not using them.
We also need to keep in mind that even though we provided a very extensible schema as a standards organization we are not promoting customization, so if we can get people who are using standard versions of FIXML to be able to ignore the custom groups in their code - all the better 
If the minOccurs=0 on groups helps this great - let’s do it.
Also, folks are working on schema compilers for runtime - Kevin has something he is doing now with the repository. I think Geoff was working on something as well. I look forward to these innovations in the near future. They will be valuable contributions.
Jim
> Sik,
> Take Castor out of the equation again. The fundamental point here is that the header was designed with element within element within element etc…
>
> I agree with your point that changes should not be made to satisfy a particular third party tool. But, it is not about that. Castor just happens to bring some issues to light. Issues that effect a promising and growing technology, "Code Generation". In particular code generation using XML Schema.
>
> This aspect(code generation) of schema design may not of been considered when creating the FIXML 4.4 schema.
>
> I see a parallel here with database schema design and the data modeling concepts of normalization and de-normalization. Normalization is used to put together a well designed schema then reality(a.k.a performance issues) forces de-normalization of the schema so that we can get it to production.
>
> A final thought, I do believe some sort of custom schema processing (as you suggest), most likely with XSLT, by the implementor (me) is a valid counter argument.
>
> Just trying to follow my dream of actaully getting something that works right out of the box for once. 8 )
>
> > Gerry,
> >
> > This problem stems from the same issue with castor as mentioned in your other email (set minOccurs of ElementsOptional and Custom to 0) to which I had responded. Again, I advise against making the change. It is part of a bigger problem, either we flatten EVERYTHING, or we dont do it at all.
> >
> > Sik.
> > Alberta Market Solutions Ltd.
> > M: +1-403-714-2288
> > F: +1-403-685-4025
> > P: +1-403-246-5104
> > E: sik.ngai@albertasolutions.com
> >
> >
> > > My last one, I promise.
> > >
> > > Again my motivation here is what the Java class code generation looks like after processing the FIXML schema.
> > >
> > > Here is an example of the number of classes it takes to build a header object using the FIXML schema as is and processed by Castor( from www.exolab.org):
> > > ------------------------------
> > > // Create and set Sender
> > > Sndr sender = new Sndr();
> > > sender.setID( "GLFIX");
> > >
> > > // Create and set Target
> > > Tgt target = new Tgt();
> > > target.setID( "GCC");
> > > target.setSub("GCC");
> > >
> > > // Create and set onBehalfOfCompID
> > > OnBhlfOf onBehalfOf = new OnBhlfOf();
> > > onBehalfOf.setID( "SSGMGCC");
> > > onBehalfOf.setSub("SSGMGCC");
> > >
> > > // Create required header elements.
> > > BaseHeaderElementsRequired headerEleReqd = new BaseHeaderElementsRequired();
> > > headerEleReqd.setSndr( sender);
> > > headerEleReqd.setTgt( target);
> > >
> > > // Create optional header elements.
> > > BaseHeaderElementsOptional headerEleOpt = new BaseHeaderElementsOptional();
> > > headerEleOpt.setOnBhlfOf( onBehalfOf);
> > >
> > > // Create and set header.
> > > Hdr header = new Hdr();
> > > header.setBaseHeaderElementsRequired( headerEleReqd);
> > > header.setBaseHeaderElementsOptional( headerEleOpt);
> > > header.setPossDupFlag("N");
> > > header.setSnt(sntDt);
> > > -----------------------------
> > >
> > > You end up creating SIX objects to put together a header object.
> > >
> > > Here is sample code for getting the SenderCompID from this composite of objects:
> > > System.out.println( "SenderCompID: "+ord.getHdr().getBaseHeaderElementsRequired().getSndr().getID());
> > >
> > >
> > > It takes FOUR function calls to get a Sender ID. Ideally all I would want to do is ord.getHdr().getID(), cutting the number of method calls in half.
> > >
> > > If your building or routing thousands of orders/executions then this is going to raise performance concerns.
> > >
> > > I like the design of MessageHeader_t, but because of the code generation consequences, I ask that the committee consider that the header be flattened, meaning that attributes be used for most values. More specifically, remove the layers consisting of BaseHeaderElementsX and the layer below consisting of onBhlfOf, DlvrTo, and Hop.
> > >
> > > Gerry Capone
> > >
> >
>