Philip, Sounds like an interesting problem and challenge. Give me a little time to think about it.
Dave On Mon, Jan 16, 2017 at 12:41:27AM +1100, Philip Haynes wrote: > 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 -- Dave Kuhlman http://www.davekuhlman.org ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
