Dave, Thank you for the quick reply. Your explanation of dateTime demystifies generates’ behavior. Let me know if there is anything else I can do to help. Glad to see the development of this awesome tool is still alive and kicking!
-Paul > On May 1, 2019, at 8:11 PM, Dave Kuhlman <dkuhl...@davekuhlman.org> wrote: > > Paul, > > Here are a few comments. > > First, unfortunately, this schema has complexities that `generateDS` > does not handle. > > About `dateTime` -- `xs:dateTime` is a simple, built-in type. > Simple means that it's something like a string, float, or integer, > and that it has no parts or elements in it. Built-in means that it > is predefined in the XML Schema specification, and the schema does > not have to define it with `xs:simpleType`. (see > https://www.w3.org/TR/xmlschema-0/#SimpleTypeFacets > <https://www.w3.org/TR/xmlschema-0/#SimpleTypeFacets>) `generateDS` > knows this, but for some reason, it believes that particular > reference to a `dateTime` is an `xs:complexType` for which there is > a generated Python class, and so it is trying to create an instance > of that class. That's wrong. The specific field, `origin`, is > defined as containing a `gml:TimeInstantPropertyType`, and it > should, I believe, be creating an instance of that class. I'll try > to track this down. Thanks for pointing me at that sample XML data > file; I've been able to reproduce this exception. > > With respect to the other bug you describe: > > AttributeError: 'CurveSegmentArrayPropertyType' object has no > attribute ‘ArcByCenterPoint' > > I have not yet been able to figure much out about this one. I need > to fix the `dateTime` issue so that I can debug this one. Then I'll > work on figuring out what a `CurveSegmentArrayPropertyType` *should* > contain. > > By the way, the issue about defining the same name in multiple > namespaces has changed. I've added code to deal with that problem. > However, that added feature is new and was added only a couple of > weeks ago. So, it is possible that there are bugs and corner cases > related to it that have not yet been shaken out. > > I'll report back when and if I've been able to fix some of the > above. But, that might not be real soon. We'll see. I apologize > for the bad news. > > And, thank you for your detailed report. That has been and will be > very helpful as I try to track down and fix these issues. > > Dave > > On Tue, Apr 30, 2019 at 04:34:51PM -0400, Paul Vajda wrote: >> Hello, >> >> I recently found your generateDS python tool to convert XML Schema >> into python data structures and was hoping you could lend me a >> hand. I found the SourceForge page but form the looks of it it >> seems the support threads have not been active in a few years, so >> I thought I might send you the question directly to make sure you >> saw it. I apologize in advance and would gladly post in the >> forums so we could discuss there if you’d prefer. >> >> After two days of banging my head against the wall, here is where >> I am at... >> >> I’m attempting to generate a python data structure using the AIXM >> XML Schema, found here (under AIXM Data - first link AIXM 5.1): >> https://www.faa.gov/air_traffic/flight_info/aeronav/aero_data/NASR_Subscription_2019-04-25/ >> <https://www.faa.gov/air_traffic/flight_info/aeronav/aero_data/NASR_Subscription_2019-04-25/ >> >> <https://www.faa.gov/air_traffic/flight_info/aeronav/aero_data/NASR_Subscription_2019-04-25/>> >> >> That directory contains the following: >> ISO_19136_Schemas (directory) >> ISO_19139_Schemas (directory) >> message (directory) >> xlink (directory) >> AIXM_Features.xsd >> AIXM_DataTypes.xsd >> AIXM_AbstractGML_ObjectTypes.xsd >> >> By comparing with AIXM compliant XML documents, I figured out that >> /message/AIXM_BasicMessage.xsd had to the schema used in the >> command line to obtain a complete data structure. In other words, >> AIXM_BasicMessage.xsd contains references to AIXM_Features, >> DataTypes and so forth, witch in turn contain references to >> schemas contained in the ISO_19136_Schemas directory. >> >> I first tried a simple command in my terminal window: >> >> ../../.././bin/python3 generateDS.py -o testingAIXM.py -s >> testingAIXMsubs.py >> ../aixmschemaTEST4/message/AIXM_BasicMessage.xsd >> >> And terminal output: >> >> *** warning. Removing child with duplicate name: "Boolean" >> *** warning. Removing child with duplicate name: "AbstractObject" >> *** warning. Removing child with duplicate name: "Curve" >> *** warning. Removing child with duplicate name: "Point" >> *** warning. Removing child with duplicate name: "Surface” >> >> And that’s it, it seems everything worked. >> >> I then tried to validate the DS by parsing the following: >> https://ext.eurocontrol.int/aixm_confluence/display/AIX/AIXM+5.1+-+sample+data+files >> <https://ext.eurocontrol.int/aixm_confluence/display/AIX/AIXM+5.1+-+sample+data+files >> >> <https://ext.eurocontrol.int/aixm_confluence/display/AIX/AIXM+5.1+-+sample+data+files>> >> : COCESNA_20170516_sample.xml >> >> However, when I attempt to parse using the parse function, I got an error: >> >> obj_ = dateTime.factory(parent_object_=self) >> NameError: name 'dateTime' is not defined >> >> Upon closer inspection, and retracing the terminal output, I found >> that at line 193311 of testingAIXM.py: >> >> elif nodeName_ == 'origin': >> obj_ = dateTime.factory(parent_object_=self) >> obj_.build(child_) >> self.origin = obj_ >> obj_.original_tagname_ = ‘origin' >> >> Indeed, searching the generated python document by generateDS, I >> could not find one instance where dateTime is defined. (! so I got >> pretty confused) >> >> Question: why do certain classes contain references to a dateTime >> class when it was never defined? >> >> So I compared the class that that snipped of code was located in >> with the XML Schema, and found that ‘origin’, in the schema, had >> as type CodeFlightOriginType. That type is defined in >> testingAIXM.py, so I replaced dateTime with CodeFlightOriginType. >> >> Doing that successfully sidestepped the error, but led to a new >> one: >> >> AttributeError: 'CurveSegmentArrayPropertyType' object has no >> attribute ‘ArcByCenterPoint' >> >> This error brought me back to your documentation on prefix >> mismatch. The schemas I’m trying to ‘pythonize’ have several >> namespace prefixes. I did find a support thread >> https://sourceforge.net/p/generateds/mailman/message/24027239/ >> <https://sourceforge.net/p/generateds/mailman/message/24027239/ >> <https://sourceforge.net/p/generateds/mailman/message/24027239/>> >> posted back in 2009. >> >> However, I have a feeling that both the errors I described above >> are two separate things, and simply manually swapping a line of >> code for another does not actually fix anything.. >> >> Questions: >> >> In response to Erica’s question (2009), you did mention that >> generateDS only supported one namespace prefix. Since 2009, has >> that changed? I tried defining multiple namespace prefixes using >> the -a flag but that didn’t work. I also tried re-running my >> terminal command with only one namespace prefix: -a “aixm:” but >> that did not change the output testingAIXM.py What actually does >> specifying the namespace prefix do? After searching a bit I found >> that in ISO_19136_Schemas/geometryPrimitives.xsd, >> CurveSegmentArrayPropertyType does refer to ArcByCenterPoint. >> (http://www.datypic.com/sc/niem21/t-gml32_CurveSegmentArrayPropertyType.html >> <http://www.datypic.com/sc/niem21/t-gml32_CurveSegmentArrayPropertyType.html >> <http://www.datypic.com/sc/niem21/t-gml32_CurveSegmentArrayPropertyType.html>>) >> Do you have any recommendations of actions I could try on my end >> to debug this? >> >> I greatly appreciate your help and look forward to hearing back, >> >> Thank you, >> >> -Paul >> > > -- > > Dave Kuhlman > http://www.davekuhlman.org <http://www.davekuhlman.org/>
_______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
