> From: Ryan <ryle...@gmail.com> > Sent: Monday, April 13, 2009 10:35:20 AM > > Hey Dave, > > I recently discovered generateDS.py and I must say that it's > saved me a lot of time. Thanks for your time and effort on this > useful tool. >
Ryan - You are welcome. Glad it was helpful. Thanks for the comment. > I did have a few small comments/questions about it, though. > > > 1) What is actually the latest version? It seems to be 1.16d but I > did note that http://sourceforge.net/projects/generateds/ shows > 1.16c Updating the version at SourceForge takes me 1/2 hour of manual work, so I sometimes get lazy. I'm in the middle of a few fixes to generateDS.py now, so I'll try to upload a new version and bring my Web site and the SourceForge version back in sync in a couple of weeks. > > > 2) In the documentation > (http://www.rexx.com/%7Edkuhlman/generateDS.html), there is an > option --external-encoding, but this doesn't seem to be > available in 1.16d. > Oops. This is code that got left behind. Thanks for catching this. I likely will not give it top priority, but when I get some time, I'll work it back in. > > 3) I noticed that when using export(), for some elements there is > an extra, unnecessary, space occurring after the element name. > e.g. > > <A>44</A> > <B > > <C > > <D > > ... > > Seems like this isn't too difficult to fix in generateExportFn(), > so I was wondering if it was intentional? > No. I was just too lazy, and did not think it would make any difference. > 4) I noticed that when I export() even the root element no xml processing > instruction is written so that a valid XML document is formed. > Do you recommend making a simple wrapper function to add the > <?xml ... >? > Take a look at the export() and exportString() functions (the ones generated at the module level). They each write out the "<!xml ... ?>" line. If the export() methods in the classes generated for each type did this, then the processing instruction would be written out repeatedly as the export methods are called recursively. I suppose each class could contain an export2doc() method. But, I'm not sure whether that's worth doing. Let's think about it. > 5) I had issues with schemas that include other schemas. One of the > problems seems to be that process_includes.py doesn't seem to > check for ElementTree in the standard location, xml.etree. > Hmm. Looks like process_includes.py is not checking for ElementTree at all. I wonder if there is some reason for that. I don't remember. I just looked at process_includes.py briefly. It doesn't seem to be using any capability from lxml that is not in ElementTree. I'll have to do some testing. > Thanks in advance for your time. > You're welcome. And, thanks for your helpful comments and questions. I'm off for a week's vacation tomorrow. We're going to Chicago to see the architecture and the sights. But, I'll work on the above itemss when I get back. - Dave -- Dave Kuhlman http://www.rexx.com/~dkuhlman ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
