[This message was posted by Alan Tang of Credit Suisse <[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/0dc9c1bf - PLEASE DO NOT REPLY BY MAIL.]
> It has been several years since we optimized FIXML. That work was completed > in 2004. The original premise which led to an elaborate schema design was to > use the FIXML Schema documents as the FIX Repository (we had no repository at > the time) AND as an extension of that permit people to define their own > implementation in "-impl.xsd" files that could be exchanged with > counterparties. This all was well and good - except (and thankfully for this) > Kevin Houstoun created a separate repository that was first a database - then > was converted to XML documents. Regarding the pattern to use the -impl files, > there was a reliance on the xs:redefine feature of XML Schema. First issue > there were some slight restrictions in using it so we ended up having to > populate enumerated fields in the fields-impl file (quite ugly) and secondly > to this day (as far as I have checked) xs:redefine is not supported by > mapping tools, such as JAXB, JIBX, etc. So the redefine feature was replaced > by xs:include but the -impl files remain. > > So we are saddled with excess complexity in the FIXML Schema for negligible > or no benefit. > > I talked with someone from the CME who said we should really consider > simplifying the FIXML Schema. If she chooses to identify herself on this > thread that would be great. CME is finding the FpML schemas easier to extend > and work with. > > I could not agree more. I could probably agree more - but my being in full > agreement is sufficient enough. > > I think the main thing we could do is eliminate the redefines and the -impl > files. That may be sufficient. What do others think? > > I like having the datatypes and fields and components in separate XSD files. > Similar to ISO 20022 - I am wondering if it makes sense to create instance > files for each message - or should we leave the category level grouping? > > In addition to simplifying the main schema, some folks who may wish to chime > in on this post as well, have created "run time" or "instance" schemas - bare > bones definitions with one XSD file per message using native XML datatypes > where possible without referring to other external schema files, such as a > datatype, field, or component file. This has some definite benefits for those > who would like to attempt runtime schema validation (though we almost always > talk in terms of milliseconds added to processing time per message for > validation - so the widespread usage of this is dubious - although likely > software performance and CPU advances can leave validation of a FIXML message > sub 1 millisecond it adds up in this day and age). > > Any other items, besides elimination of the -impl files anyone else can > recommend. > > One of the thought leaders behind FpML made a very strong case in a chat > session recently to limit the namespace to "FIX5" and to use the attributes > on the message for further clarification of service and extension pack. I > think this has considerable merit considering the difficulty in having to > change the namespace on existing messages. > > Further thoughts on this are appreciated. Don't feel compelled to comment - > if you don't have informed opinions - being a reader is a sufficient > contribution. > > It would be good to know what challenges and/or problems have occurred in > using the FIXML Schema. > > > > > > > We like the -impl.xsd design since it serves the original design goal: extensibility. Our customization is on two -impl files: fixml-fields-impl-5-0-SP2.xsd and fixml-components-impl-5-0-SP2.xsd. To extend enum values, we create simpleType in fields-impl, then use <xsd:union> to expand the existing enum type. To extend attributes of a type, we define the additional attribute value types on fields-impl, then in components-impl we use <redefine> to override the target complex type, and add new attributes using the attribute value types. I concur that <redefine> is not well supported by most xml mapping tools (such as xsd.exe in C#). This is a problem for us to generate the class files from the schema. We had to find some workaround. I agree to the problem of constraint on <redefine>, but I think -impl design is very valuable, unless there is another way to to simplify the schema yet still achieve extensibility. [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.
