Eugene, I'll get on it tomorrow.
> * I noticed that utils/collect_schema_locations.py only collects includes, > not imports. I can't believe I forgot that. Should teach us not to hire cheap help. Thanks for catching it. > * We somehow need to deal with nested imports/includes. The > utils/collect_schema_locations.py only collects imports from the input > file, but not from the schemas it imports/includes. Probably a solution > would be to recursively scan files and put all required schemas in the > directives.json file. This one we need to think about. I suspect that we do not want to generate so many modules. Let me think and comment a bit more, tomorrow. Dave On Thu, Jun 08, 2017 at 03:07:34AM +0300, Eugene Petkevich wrote: > Dave, > > Thank you for the response and excuse me for the late answer. > > 1) Regarding the utils/collect_schema_locations.py and > utils/batch_generate.py. > > When I ran the commands you've provided on the xsd file: > > $ ./collect_schema_locations.py -f > energistics/prodml/v2.0/xsd_schemas/DasAcquisition.xsd directives04.json > $ mkdir OnePer3 > $ ./batch_generate.py --config=gds02.config directives04.json > > I've got an error from which I see what probably was a reason with > --one-file-per-xsd argument in my case. I see that there is a circular > import in schema files (gmd.xsd imports gts.xsd which imports gml.xsd > which again imports gbd.xsd and so on). So utils/batch_generate.py says > it cannot find a file with a very long path that comes from that looped > reference, like > > '../../../../gml/3.2.1/../../iso/19139/20070417/gmd/../../../../iso/19139/20070417/gts/../../../../gml/3.2.1/../../iso/19139/20070417/gmd > ... etc'. > > So here are my comments: > > * I noticed that utils/collect_schema_locations.py only collects includes, > not imports. > * We somehow need to deal with nested imports/includes. The > utils/collect_schema_locations.py only collects imports from the input > file, but not from the schemas it imports/includes. Probably a solution > would be to recursively scan files and put all required schemas in the > directives.json file. > * Then, circular imports/includes should be supported. I guess that may > be a complicated thing. For collecting/loading schema files a solution > would probably be to manage a set of already discovered schemas. But not > sure how complicated would be to generate classes, we probably need to > generate them in a correct order. How complicated do you think that would > be? > > I can try to help you with this. Just tell me if you have any comments > regarding what I've written. > > *Update*: > > Actually, I've tried to run again generateDS.py on the xsd and it gives > the same error (about file not found with circulare import). I'm not sure > why it worked before and does not work now on the same file. I've tried > both the newest version of generateDS and the old one I've used before, > both lead to the same error. > > Ok, after trying out more I figured out that only happens when I used > absolute path to the xsd file. Do you have any idea why absolute path may > be a problem? Then I'm not sure whether my comments are still > applicable. As I understand now, circular imports/includes are supported > in generateDS.py itself, but somehow not in case of --one-file-per-xsd. > Still I see a reason to search for xsd files recursively and make one file > for each of those xsd files. > > 2) Namespace definition behavior. > > I see that your new --no-namespace-defs argument works fine. I currently > don't see a use case for manually choosing namespace definitions with > dictionary, but that could be useful. The reason to have only top-level > namespace is to make an xml files more readable and smaller, by using > namespace definition only where needed. Though yes, probably in some > cases it would be needed to have it not in the top, maybe when using same > namespace name for different namespaces in different parts of the xml... > > 3) Other issues I've mentioned before. > > Do you have a plan at which issue to look next? Maybe I can try to > investigate another one meanwhile. > > 4) One more thing I want to mention -- in generated code positional > arguments are used for export, __init__ and other functions. When > sublclassing it is more convenient when keyword arguments are used, since > we can get value of a particular element by its name. I think it could > make sense to change positional arguments to keyword arguments at least in > the autogenerated code. Though I'm not sure that it would help if a user > uses positional arguments. > > Best regards, > Eugene > > On 27.05.2017 00:20, Dave Kuhlman wrote: > [snip] -- 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
