Hello Dave, Thanks for the fast, elaborate and clear reply. Sorry for not being clear. My (example) code is in the repository I listed in the beginning of my mail. I could have better copied some lines of code in my question, I now realize.
You’re second option is the one I was referring to. I also tried the first (reading an XML, do some processing and write it back to XML) and that worked flawlessly (as long as I don’t add new instances from abstract classes. Using the debugger with the generated code, I already found the two relevant variables you mention (original_tagname_ and extensiontype_). I was expecting that these two were properly set in the add_asset method. Is there a reason not to add this for all cases where there is a containment relation with an abstract class in the XSD? This would prevent having to do it manually each time... Regards, Edwin Verstuurd vanaf mijn iPhone > Op 15 okt. 2018 om 22:43 heeft Dave Kuhlman <dkuhl...@davekuhlman.org> het > volgende geschreven: > > Edwin, > > Good to hear from you. > > You did not mention how you created the instances of the Python data > binding classes (generated by generateDS.py from your schema). Did > you (1) create them by using those classes to parse an XML instance > document and then export it to XML? Or, (2) did you create those > instances manually by writing your own Python code? > > If you did the second, then there is a special way in which your > Python code must create those instances so that they know that they > must export themselves with the xsi:type="xxx" attribute. > > I recently had a question about this same issue, again *if* it's the > second way of creating instances that we are talking about. If it > is, then you can either take a look at my answer to a question about > that issue here: > https://sourceforge.net/p/generateds/mailman/message/36433595/ > > Or, better yet, I believe, look at this addition I made in response > to that question to the `generateDS` documentation in section "Types > derived by extension": > http://www.davekuhlman.org/generateDS.html#types-derived-by-extension > > Here is an attempt to reproduce what I *think* you are trying to do: > > I generated a module from `EsdlXML.xsd`: > > $ ./generateDS.py -o esdlxmllib.py EsdlXML.xsd > > Then I ran this Python code: > > # sample03.py > import sys > import esdlxmllib > > def test(): > instance = esdlxmllib.Instance() > area = esdlxmllib.Area() > asset = esdlxmllib.WindTurbine() > asset.original_tagname_ = 'Asset' > asset.extensiontype_ = 'WindTurbine' > area.add_asset(asset) > instance.area = area > instance.export(sys.stdout, 0) > > test() > > And, it printed out this: > > $ python sample03.py > <esdl:Instance xmlns:esdl="http://www.tno.nl/esdl/180901";> > <esdl:area xmlns:esdl="http://www.tno.nl/esdl/180901";> > <esdl:Asset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:type="WindTurbine"/> > </esdl:area> > </esdl:Instance> > > Is that what you are trying to get? I've attached the above sample > code (sampe03.py), in case it's helpful. > > If the above does not help you solve your problem, please give me a > little more information to work with, so that I can reproduce your > problem. > > Dave > >> On Sat, Oct 13, 2018 at 04:37:06PM +0000, Matthijssen, E.F. (Edwin) via >> generateds-users wrote: >> Hello, >> >> We've developed a model for energy systems using the Eclipse >> Modeling Framework and we're trying to use GenerateDS to create >> python classes. The project is hosted here: >> https://github.com/EnergyTransition/ESDL-Python >> >> A picture of the class diagram can be found here: >> https://github.com/EnergyTransition/ESDL/blob/master/esdl/model/esdl.png >> >> The Eclipse tooling allows exporting the model as an XML schema >> definition. There are two different options: - An xsd based on >> XML: >> https://github.com/EnergyTransition/ESDL-Python/blob/master/model/EsdlXML.xsd >> - An xsd based on XMI: >> https://github.com/EnergyTransition/ESDL-Python/blob/master/model/esdlXMI.xsd >> >> No matter what xsd we use as an input, we get undesired output >> when we try to write an instance of a EnergySystem to a file. >> >> The problem exists where we use a collection of an abstract class, >> with many sub classes. In the example below area is an instance of >> class Area. An Area can contain 0 to many (0..*) Assets. Asset is >> an abstract class and WindTurbine is a subclass of Asset. >> >> The desired output should look like this: >> >> <esdl:EnergySystem> >> <esdl:instance> >> <esdl:area> >> <esdl:asset xsi:type="esdl:WindTurbine"> >> ... >> </esdl:asset> >> </esdl:area> >> </esdl:instance> >> </esdl:EnergySystem> >> >> Using the XML version of the XSD, the output looks like: >> >> <esdl:EnergySystem> >> <esdl:instance> >> <esdl:area> >> <esdl:WindTurbine> >> ... >> </esdl:WindTurbine> >> </esdl:area> >> </esdl:instance> >> </esdl:EnergySystem> >> >> Using the XMI version of the XSD, the output looks like: >> >> <esdl:EnergySystem> >> <esdl:instance> >> <esdl:area> >> <esdl:asset> >> ... >> </esdl:asset> >> </esdl:area> >> </esdl:instance> >> </esdl:EnergySystem> >> >> Any ideas how to get this right? Any help is highly appreciated >> >> Regards, >> Edwin >> >> >> >> >> 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. > > >> _______________________________________________ >> generateds-users mailing list >> generateds-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/generateds-users > > > -- > > Dave Kuhlman > http://www.davekuhlman.org > <sample03.py> _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
