Philip,
I'm glad you have a solution for this (and an ingenious one, too),
because I don't understand it.
Since you seem to have a solution, please don't much spend (waste)
too much time with the following, but ...
When I use this schema to generate a module:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
<xs:element name="container" type="containerType"/>
<xs:complexType name="containerType">
<xs:sequence>
<xs:element name="field1" type="xs:string" minOccurs="0"/>
<xs:element name="field2" type="xs:string" minOccurs="0"/>
<xs:element name="field3" type="simpleStringType"
minOccurs="0"/>
<xs:element name="field4" type="simpleStringType"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="simpleStringType">
<xs:simpleContent>
<xs:extension base="xs:string">
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
And, then I use the generated module to parse and export the
following XML instance doc:
<?xml version="1.0"?>
<container>
<field3>an ascii string</field3>
<field4>Selçuk < > İstanbul</field4>
</container>
What I see is the following:
<?xml version="1.0" ?>
<container>
<field3>an ascii string</field3>
<field4>Selçuk < > İstanbul</field4>
</container>
As you can see, the exported tag name is the element name
(<xs:element name="container" ...), and *not* the type name
(<xs:complexType name="containerType" ...).
So, am I interpreting your question wrong? Or, is there something
about your XML schema that makes a difference? Does it have
something to do with the substitutionGroup?
Is it a bug? Or, can I ignore this one?
Dave
On Tue, Jan 17, 2017 at 02:30:45PM +1100, Philip Haynes wrote:
> Thanks Dave,
> One update. I have changed my workaround to append some code to the
> bottom of the generated file to create subclasses for all my named
> elements. I think this will work for me;
>
> for name, base_class in GDSClassesMapping.items():
> def custom_init(self, *args, **kwargs):
> super(self.__class__, self).__init__(*args, **kwargs)
> self.original_tagname_ = self.__class__.__name__
> type(name, (base_class,), {'__init__': custom_init})
>
> I need this rather than just changing it on export since some of the
> more complex structures were nesting the classes I want to rename and
> I thus lost control of being able to call my custom export_mapped
> function all the way down (I originally had a problem with recursive
> inheritance when trying to do that and am somewhat too time
> constrained for my first instance implementation to work around that
> issue).
>
> I quite like this new approach and figured it might be helpful.
>
> Regards,
> Philip
>
> On 17 January 2017 at 11:11, Dave Kuhlman <dkuhl...@davekuhlman.org> wrote:
> > 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
>
>
>
> --
> Philip Haynes
> Director, Dayneson Pty Ltd ATF the Davidson Haynes Family Trust
> Address: 33 Arthur Street. Dee Why. NSW. 2026. Australia
> Email: phi...@dayneson.mine.nu
> Mobile: +61411050016
--
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
