Hi Dave, I discovered another issue related to the discussion below. I thought that the "xsi:type" was only required when there is a containment (composition) relation with an abstract class with cardinality [0..*]. In these cases you now provided the add_xxx_with_type methods. But the same problem appears, when the cardinality is [0..1], in case only an add_xxx and a set_xxx are generated. Basically we then also need an set_xxx_with_type (or incorporate this in the add_xxx and set_xxx if we agree that this is the generic required behavior).
Regards, Edwin -----Original Message----- From: Dave Kuhlman <dkuhl...@davekuhlman.org> Sent: maandag 29 oktober 2018 23:40 To: Matthijssen, E.F. (Edwin) <edwin.matthijs...@tno.nl> Cc: generateds-users <generateds-users@lists.sourceforge.net> Subject: Re: [Generateds-users] Problems with code generated by GenerateDS Edwin, Thanks for your changes. I'm traveling right now, seeing a part of the country that I've never been in before, specifically Ohio and a little bit of Kentucky, U.S.A. I've spent most of my life in various parts of California. So, I'll take a look when I get home in a couple of days. About the excessive namespace prefix definitions -- I slept on this one and mumbled in my sleep a bit on it. It would certainly be a good thing to do. But, I suspect it would also be challenging. For one we don't know in advance (at code generation time) what the root node (class) is, because an XML schema can define multiple root nodes, that is, it can have multiple element definitions at top level. For another, a user, writing Python code and importing the generated code as a module can export any node (class) and not necessarily the root or top level node. Still, there must be something we can do to reduce this clutter. I'll think some more on it when I get home. Perhaps there is some way to tell child nodes/classes which namespace prefixes have already been defined. Thanks for the suggestion and the nudge. Dave On Sat, Oct 27, 2018 at 09:02:07PM +0000, Matthijssen, E.F. (Edwin) wrote: > Hi Dave, > > Today I found time to check your changes. It did not generate valid XML for > me though. Therefore I also spent time to debug both the generated Python > code and the generateDS python code, to get a good understanding of what is > happening where and when. > > To get a valid XML, I changed two things in the generateDS.py code (see > attached file, changes marked with '#Edwin'). I'm not sure if this would be > the way you would do it, however, you probably get the point of what is > needed by looking at my proposed changes. I'm also not sure if these changes > are generic enough and valid for all cases. > > I have one more thought. Right now you're adding definitions of namespaces at > every location where you use these namespaces. This leads to quite elaborate > XML code. Another option worth considering is defining the namespaces once at > the top of the XML (as an attribute of the root element). > > I'm curious about your thoughts. Let's keep in touch... > > Regards, > Edwin > > -----Original Message----- > From: Dave Kuhlman <dkuhl...@davekuhlman.org> > Sent: maandag 22 oktober 2018 22:18 > To: Matthijssen, E.F. (Edwin) <edwin.matthijs...@tno.nl> > Subject: Re: [Generateds-users] Problems with code generated by > GenerateDS > > Edwin, > > Attached is the modified version of `generateDS.py`. > > Also attached is a script (`sample04.py`) that will test it. You can run it > as follows: > > $ generateDS.py -o animalslib.py animals.xsd > $ python sample04.py > > I'll be travelling for the rest of this week and half of the next, but will > get back on this when I return. I need to do more testing on this. I worry > that an element name with a dash in the middle will cause a problem. And, I > should create a unit test. > > I'll welcome your thoughts and suggestions. > > Dave > > -- > > Dave Kuhlman > http://www.davekuhlman.org > This message may contain information that is not intended for you. If you are > not the addressee or if this message was sent to you by mistake, you are > requested to inform the sender and delete the message. TNO accepts no > liability for the content of this e-mail, for the manner in which you use it > and for damage of any kind resulting from the risks inherent to the > electronic transmission of messages. -- Dave Kuhlman http://www.davekuhlman.org _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
