I think that's it, Dave! Glad to know it's currently supported after all! Thanks for your time and patience. The updated documentation looks great and should definitely help anyone else running into similar issues.
On Thu, Oct 4, 2018 at 5:57 PM Dave Kuhlman <dkuhl...@davekuhlman.org> wrote: > Justin, > > I'm groping here. In part because it is certainly possible that the > code generated by `generateDS.py` does not fit your use case well. > But, let me try. > > If you look in the generated code at method `animalCollection.build` > and `animalCollection.buildChildren`, you will see that it captures > the value of the `xsi:type` attribute and then eventually builds an > instance of class `dog`. I stepped through this code with the > debugger (`pdb`, actually `ipdb`) to make sure that this happens. > Also notice the following line at the end of > `animalCollection.buildChildren`: > > obj_.original_tagname_ = 'animal' > > That is part of what tells it to generate an "<animal>" with an `xsi:type` > attribute instead of a "<dog>". The other piece is > `obj_.extensiontype_`. > > So, attempting to answer your question: How do I create a `dog` that > is derived from `animal`? -- You build an instance of class `dog`, > but set its `original_tagname_` to "animal" and its `extensiontype_` > to "dog". In order to test this, I did it as follows (see > sample01.py, in the attached zip file): > > import sys > import example01 > > def test(): > animal_collection = example01.animalCollection() > animal = example01.dog(name='milicent') > # > # must set original_tagname_ and extensiontype_ for > # type derived by extension. For info, see: > # https://www.w3.org/TR/2004/REC-xmlschema-0-20041028/#DerivExt > animal.original_tagname_ = 'animal' > animal.extensiontype_ = 'dog' > animal_collection.add_animal(animal) > animal_collection.export(sys.stdout, 0) > return animal_collection, animal > > test() > > Run it and you get: > > $ python sample01.py > <animalCollection> > <animal xmlns:xsi=" > http://www.w3.org/2001/XMLSchema-instance"; xsi:type="dog"> > <name>milicent</name> > </animal> > </animalCollection> > > Does get you on the road toward what you are trying to accomplish? > If not, let me know, and give me a bit more guidance. > > Hope so. Whew. I had to grope and stumble through this in a > debugger. > > It's certainly not obvious. I'll try to add a note on this to the > `generateDS` documentation. (done) > > Maybe I'd best add a unit test, also. (done) > > Hope this helps. And, thanks for pushing me to work through it. > It's something I should understand, myself. > > Dave > > On Wed, Oct 03, 2018 at 08:54:29PM -0400, Justin McManus wrote: > > Ok, I'll admit that maybe I'm missing something here, but I'm really not > > sure how to add an animal of type dog to the animal collection then, > which > > is the semantically valid XML required by the schema I'm working with. > E.g. > > this doesn't work: > > > > dog = example.animal("dog") > > dog.name = "fido" > > animalCollection.add_animal(dog) > > (the name is dropped from the output xml) > > > > How can I add the dog-specific fields (i.e. name) to an <animal > > xsi:type="dog">? If I export the dog from the above snippet, I get: > > > > <animal xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > > xsi:type="dog"/> > > > > On Wed, Oct 3, 2018 at 6:32 PM Dave Kuhlman <dkuhl...@davekuhlman.org> > > wrote: > > > > > Justin, > > > > > > Patient: "Doc, it hurts when I do this." > > > Doctor: "Then don't do that." > > > > > > Lord, I've waited entirely too long to tell that joke. But, > > > seriously, ... > > > > > > If I understand you correctly, you are saying that the code > > > generated from `example.xsd` allows you to do this: > > > > > > # test02.py > > > import sys > > > import example01 > > > > > > def test(): > > > animalcollection = example01.animalCollection() > > > dog = example01.dog(name="frisky") > > > # add a `dog` to `animalcollection.animal`. > > > animalcollection.add_animal(dog) # should not do this. > > > animalcollection.export(sys.stdout, 0) > > > > > > test() > > > > > > So, I'm saying: "Don't do that." > > > > > > Again, more seriously, are you suggesting that the code generated by > > > `generateDS.py` should block you from adding a `dog` to > > > `animalcollection.animal`? We can talk about whether those > > > generated bindings should prevent you from adding the wrong type of > > > object to a child collection. Possibly, that would be a good > > > enhancement, though I'm not sure. But, yes, you are right, the > > > generated code provides no such protection. > > > > > > And, yes, if you run the above code, it produces something we do not > > > want: > > > > > > $ python test02.py > > > <animalCollection> > > > <dog> > > > <name>frisky</name> > > > </dog> > > > </animalCollection> > > > > > > And, actually, you can do silly things like the following, also: > > > > > > class Goofy(): > > > pass > > > > > > bad_dog = Goofy() > > > animalcollection.add_animal(bad_dog) # should not do this. > > > > > > Do we really want the generated bindings to be checking for these > > > mis-uses? I suppose this would mean that generated functions > > > `animalCollection.set_animal()` and `annimalCollection.add_animal()` > > > would need to do this checking. What about the constructor? Should > > > it check each argument also? That seems like a lot of possibilities > > > to check for. What do you think? > > > > > > Do I understand you correctly on this? > > > > > > Dave > > > > > > On Wed, Oct 03, 2018 at 01:06:24PM -0400, Justin McManus wrote: > > > > Thanks for your response, Dave. Sorry for the incomplete example. To > > > > continue with your much better example, the problem occurs when > another > > > > complex type, let's say "animalCollection", lists "animal" as an > element. > > > > In this case, we can add a dog to the collection just fine using the > > > > generated bindings, however schema validation will fail since the > > > > collection is only expected to contain animal. I've attached some > working > > > > (well, you know what i mean :) examples this time. > > > > > > > > xmllint --schema example.xsd example-bad.xml > > > > <?xml version="1.0"?> > > > > <animalCollection> > > > > <dog> > > > > <name>fido</name> > > > > </dog> > > > > </animalCollection> > > > > example-bad.xml:3: element dog: Schemas validity error : Element > 'dog': > > > > This element is not expected. Expected is ( animal ). > > > > example-bad.xml fails to validate > > > > > > > > xmllint --schema example.xsd example-good.xml > > > > <?xml version="1.0"?> > > > > <animalCollection xmlns:xsi=" > http://www.w3.org/2001/XMLSchema-instance";> > > > > <animal xsi:type="dog"> > > > > <name>fido</name> > > > > </animal> > > > > </animalCollection> > > > > example-good.xml validates > > > > > > > > > > > > > > > > On Tue, Oct 2, 2018 at 4:57 PM Dave Kuhlman < > dkuhl...@davekuhlman.org> > > > > wrote: > > > > > > > > > Justin, > > > > > > > > > > Oops. The output from xmllint in my previous message used a > > > > > slightly extended .xsd and .xml. > > > > > > > > > > Here is the output from the two files I actually attached: > > > > > > > > > > $ xmllint --schema test01.xsd test01.xml > > > > > <?xml version="1.0"?> > > > > > <dog> > > > > > <name>jasmine</name> > > > > > </dog> > > > > > test01.xml validates > > > > > > > > > > Dave > > > > > > > > > > On Tue, Oct 02, 2018 at 09:25:32AM -0400, Justin McManus wrote: > > > > > > Hi, > > > > > > Your generateDS library has been really useful to me, thanks. > > > > > However, I > > > > > > just found a blocking bug for my use case, and I checked > > > sourceforge > > > > > and > > > > > > bitbucket and didn't find any public issue trackers that I > could > > > > > report it > > > > > > on. I'll take a look at fixing it anyway, but I wanted to > check if > > > > > there's > > > > > > a place to report this officially, and whether you're > accepting > > > pull > > > > > > requests. > > > > > > The issue was found in generateDS 2.29.24 from PyPi. The gist > of > > > it is > > > > > > that complex subtypes are always assumed to be defined as > > > substitution > > > > > > groups, e.g. type "Dog" that extends an abstract type "Animal" > > > will be > > > > > > rendered as <Dog> instead of <Animal type="Dog">, which fails > xsd > > > > > > validation. Here's a minimal example: > > > > > > example.xsd: > > > > > > <?xml version="1.0"?> > > > > > > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; > > > version="1.0"> > > > > > > <xs:element name="SubType" type="SubType"></xs:element> > > > > > > <xs:complexType name="AbstractBaseType" > > > > > abstract="true"></xs:complexType> > > > > > > <xs:complexType name="SubType"> > > > > > > <xs:complexContent> > > > > > > <xs:extension base="AbstractBaseType"></xs:extension> > > > > > > </xs:complexContent> > > > > > > </xs:complexType> > > > > > > </xs:schema> > > > > > > $> generateDS -o example.py ./example.xsd > > > > > > $> python > > > > > > >>> import sys, example > > > > > > >>> example.SubType().export(sys.stdout, 0) > > > > > > <SubType/> > > > > > > > > > > -- > > > > > > > > > > Dave Kuhlman > > > > > http://www.davekuhlman.org > > > > > > > > > > > > <?xml version="1.0"?> > > > > <animalCollection> > > > > <dog> > > > > <name>fido</name> > > > > </dog> > > > > </animalCollection> > > > > > > > > > > > > > > <?xml version="1.0"?> > > > > <animalCollection xmlns:xsi=" > http://www.w3.org/2001/XMLSchema-instance";> > > > > <animal xsi:type="dog"> > > > > <name>fido</name> > > > > </animal> > > > > </animalCollection> > > > > > > > > > > > > > -- > > > > > > Dave Kuhlman > > > http://www.davekuhlman.org > > > > > -- > > Dave Kuhlman > http://www.davekuhlman.org >
_______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
