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
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
