[This message was posted by Namitha Jeremiah of TCS <[email protected]> to the "FIXML" discussion forum at http://fixprotocol.org/discuss/7. You can reply to it on-line at http://fixprotocol.org/discuss/read/4fd13dab - PLEASE DO NOT REPLY BY MAIL.]
Hi, I am facing an issue in converting FIXML V5.0 to java using castor. Source Generation is failing with floowing error. Kindly help us in resolving this issue. It is quite urgent. Thanks, Namitha > Hi, > > I would not entirely agree with listed defects of xsd.exe below. It is > possible to design your schema in a way, so that inheritence is > available to you when classes are generated from xsd.exe. Please read > this article for detailed explanation. > > http://www.topxml.com/xmlserializer/xmlincludeattribute.asp > > -Anand > > > An approach I've seen used at clients is to generate an object model > > in the same way that we, the FPL GTC, generate the schema. EG from the > > repository. > > > > The repository is available to FIX members on the following URL. > > http://www.fixprotocol.org/specifications/repository The is also some > > documentation and some sample XSLT that run against the repository. > > > > To generate the schema we run XSLT against the XML repository and this > > adds the mechanical bulk of the schema to the various files. The > > starting section of each file is hand crafted, the main section > > generated and a file hand crafted section is appended. (normally just > > closing tags) > > > > These XSLT, or you own can be modifed to create your own object model > > in the language of your choice. I contacted the programmer at the > > client who was doing this and he made the following comments on thier > > approach. > > > > <Comments> > > > > No, we don't generate interfaces for the objects - not really needed - > > but we could do so if someone wanted it. Yes, we generate private > > members for all properties and have proper get / set accessor methods. > > No, we don't currently mark stuff as mandatory - would be a good thing > > to add and very easy. Could then do a validation check before sending > > message from the object model - and throw exceptions if mandatory > > fields are not set. Yes, others can inherit from our objects - we also > > have a base object that all our stuff inherits from so that messages > > can be handled generically if required. Yes, we have a namespace > > XXXX.FIXObjectModel44 - one single DLL contains all messages in the > > FIX spec. No, don't currently integrate documentation tags - again > > would be easy to do and worthwhile. No, don't currently integrate > > AppInfo tags. > > > > </Comments> > > > > All this code is generated from the repository and a few XSLT > > style sheets. > > > > The FPL GTC are working on a sample object model generating XSLT that > > will be posted as a starter for anyone wishing to take this approach. > > > > Cheers Kevin Houstoun Consultant, Citigroup. > > > > > > Are you saying that code generated from tools such as xsd.exe, > > > > castor and the likes is not bug-free? what kind of bugs are you > > > > referring too for instance? > > > > > > I got a lot of experience with the xsd.exe and the FIXML xsd's the > > > last 6 month. For simple and quickly launched applications it might > > > work fine, but if you want to integrate the FIXML business model > > > into your application, you soon get very angry about the quality of > > > the source code, generated by the xsd.exe. Just some points, which > > > drove me crazy: > > > > > > - No support of interfaces > > > - No generation of properties and private members, just public > > > variables > > > - No mark of mandatory properties, no automatic constructor > > > generation with mandatory parameter > > > - Very poor inheritance support > > > - No namespace separation. You have to built several DLL's, if you > > > want to cover the complete model > > > - No integration of the documentation tags > > > - No integration of AppInfo tags. It is relevant for all the > > > enumerations, they are added as AppInfos to the schema > > > - and and and ... > > > > > > JAXB does a much better job, but still not cover all the demands. > > > > > > As we have chosen .net as the platform for GUI's, I decided to built > > > an own xsd code translator. This is the only way to get a clear > > > source code and object model out of the FIXML xsd. We found some > > > fragments in open source projects but still it took us more than 4 > > > month and a deep digging in the System.CodeDom assembly to finish > > > our compiler. > > > > > > And this makes things much more easier now! Especially integration > > > of the enumerations make the understanding of FIXML much more > > > easier. > > > > > > So, if anybody is interested about, just write an email to > > > [email protected] [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
