Hi Dave,
Rereading your email. I see that your test scenario doesn't reproduce my issue.
In my case, parsing XML produces exactly the correct result as well.
As you have found.
My problem is that if I try and create a class from my program and
"fill it out" dynamically in order to then produce the raw XML so that
I can send it somewhere else (to a server as a part of a client server
message protocol) it is then that I get the "tag name" problem. So in
your example schema I have to write
>>> myc = test.containerType(field1="a", field2="b",
>>> field3=test.simpleStringType("3.1"), field4=test.simpleStringType("Z"))
since there is no "container" class in the generated module, only
"containerType". The exported xml from that instance, myc, becomes;
>>> myc.export(sys.stdout, 0)
<containerType>
<field1>a</field1>
<field2>b</field2>
<field3>3.1</field3>
<field4>Z</field4>
</containerType>
Which displays the tag problem I am trying to solve, that is, showing
<containerType> rather than my preferred <container>. As per my
previous mail, I am happy to leave this for now. I think my work
around is mostly ok for me (note that I had a cut and paste error in
my previous message, I need to have globals()[name] = type..... as the
creation of the new type in my added code, and there be other things I
should do; like appending to __all__ as well).
Thanks again,
Philip
On 18 January 2017 at 09:48, Dave Kuhlman <dkuhl...@davekuhlman.org> wrote:
> 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
--
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
------------------------------------------------------------------------------
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
