On Tue 24 Sep 2013 06:47:28 PM PDT, George David wrote:
> Dave,
>
> Our product is an appliance. We mostly run Java, we have some c/c++ code,
> and a lot of bash, perl, and python scripts. The appliance runs on Linux.
> About a year ago we released a REST API for our customers to use. We
> generate XSDs from YANG files using pyang. Then we use JAXB to convert the
> XSD files to Java. For use in our own product. I started creating python
> scripts as a way to test our REST API. Eventually, the scripts became
> examples for how to use our REST API in python and we ship them as part of
> our samples.
George,
Wow. Very interesting. Sounds like an impressive product. Thanks for
that explanation. I'd love to learn more about the connection between
data modeling and YANG and XML schema.
More notes below.
>
> I was able to run the unit tests and I did encounter many failures, though
> most of them were cosmetic. Whitespace changes. Some of them had new
> namespace definitions where previously they were missing. One of the
> failures was because the test was expecting "ascii" as the external
> encoding, but my system Ubuntu 12.04 has a default of UTF-8.
>
> Now there are about 15 failures. They all fail with this:
>
> File "test.py", line 439, in check_result
> self.failUnlessEqual(err, len(err), 0)
> AssertionError: '' != 0
>
>
> There isn't an error, but stderr seems to be different on my system than
> yours. Have you encountered this?
You changed the arguments passed to failUnlessEqual. It seems like
a userful change. But, perhaps you really meant to change it to this:
self.failUnlessEqual(len(err), 0, err)
The third, optional, argument is a message to be displayed when the
test fails. See:
http://docs.python.org/2/library/unittest.html#unittest.TestCase.assertEqual
And, failUnlessEqual is now a deprecated alias for assertEqual.
I should have fixed that, and will try to remember to change it.
>
>
> To answer some of your questions, I am not using --no-process-includes.
> With our XSDs, almost all of them import another XSD. I needed to create
> python classes for all the XSDs. I could see though that at some point I
> may just want to generate the top-level XSD because the rest have already
> been created. I'll look into adding that functionality.
>
> I added the following options:
>
> --one-file-per-xsd Create a python class for each XSD processed.
> --output-directory="XXX" Used in conjunction with --one-file-per-xsd.
> The directory where the XSDs will be created.
> --module--suffix="xxx" To be used in conjunction with
> --one-file-per-xsd.
> Append XXX to the end of each file created.
Cool. This sounds like an exciting new capability.
>
>
> It didn't occur to me to create an __init__.py file in generateDs. Funny
> because I created a bash script to iterate over all the XSDs and execute
> generateDS for each one. That script also creates an empty __init__.py
> file. I'll look into moving this functionality into generateDS with the
> import statements you mentioned. I can also create an __all__ in this file,
> not sure if this would be redundant or not.
>
> At this point I'm going to check in the code on my fork of generateDS. It's
> at https://bitbucket.org/gsalsero/generateds-fork.
>
> Let me know if you think it's in good enough shape for me to submit a pull
> request.
Your changes look very good to me, and very impressive. Also, I believe,
if I understand it correctly, that it will very valuable to users
who need to deal with schemas that have multiple namespaces (and
namespace prefixes) in multiple .xsd files.
Please add/commit your latest changes and send me a pull request so
that I can begin to work with it.
I have a few very minor "nits to pick" (for example naming
conventions for global variables), and I'll need to add something to
the documentation, do testing, etc. You likely will need to give me
a bit of guidance with that.
Thanks so much for all your work on this.
The work you describe with YANG files and pyang sounds fascinating,
by the way, although I don't understand much of it.
Dave
[snip]
--
Dave Kuhlman
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
