Hello, I am investigating using generateDS to write a FIXML (the XML version of the FIX protocol). So far, very good results in parsing sample XML and generating a comprehensive python binding to the API. However I have a slight wrinkle. Perhaps I am using things incorrectly, but...
The FIXML xsd is quite extensive (>26000 lines spread over 43 xsd files) however inside the meat of the XML, there is a schema; <xs:schema targetNamespace="http://www.fixprotocol.org/FIXML-5-0"; xmlns:xs="http://www.w3.org/2001/XMLSchema"; xmlns="http://www.fixprotocol.org/FIXML-5-0"; xmlns:fm="http://www.fixprotocol.org/FIXML-5-0/METADATA"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://www.fixprotocol.org/FIXML-5-0/METADATA fixml-metadata-5-0.xsd" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:include schemaLocation="fixml-fields-impl-5-0.xsd"/> ... and then various SimpleType, ComplexTypes and elements. It is the elements I care about, for example; <xs:element name="UserReq" type="UserRequest_message_t" substitutionGroup="Message" final="#all"/> .... </xs:schema> Now gDS generates classes called UserRequest_message_t which I can happily instantiate and fill and then export to produce <UserRequest_message_t UserReqID="12324" UserReqTyp="1" Username="me" Password="pwd"> <Hdr SID="CCC" TID="CBB" SSub="CCCUSER" TSub="CBCB"/> </UserRequest_message_t> However I "want" the tag for this document to read "UserReq" from the name in the element, not the type. I cannot see a way to create my "UserReq" element programatically. I know that one way to get my desired XML document, would be to set the original_tagname_ attribute on the instance of the object, but I don't really want to have to do that for every instance I create. Another way would be to set the name_ parameter on calling export (likewise inconvenient). The frustrating thing is that the GDSClassMapping dictionary already does this correctly when parsing incoming XML files (albeit in reverse). So I am suspicious that I am missing something here. My current approach is to monkey patch the gDS generated module after loading to add a "export_mapped" method to the Abstract_message_t class that is the base class for the relevant elements in the XSD and with that function just call "export(..., name_ = <a magical reverse lookup on the GDSClassMapping dictionary from the exporting class to the required tag>)" thus calling export with the name_ parameter set correctly and all is good. I feel that this approach is an inelegant solution to something that could well already be solved in gDS but I just can't work it out. I have scanned the archive of this mailing list and cannot find anything that seems to be related to my "issue" and so I post on a new thread. Thanks, Philip ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
