Thanks for the quick follow up! I look forward to your fix.
--S
On Sunday, August 18, 2013, Dave Kuhlman wrote:
> > From: Shahaf Abileah
>
> >To: Dave Kuhlman <dkuhl...@rexx.com <javascript:;>>
> >Sent: Friday, August 16, 2013 4:32 PM
> >
> > I spotted what might be a bug in generate DS.
> >
> > Here's a sample XSD that illustrates the problem:
>
> Shahaf -
>
> Thanks for reporting this. And, thanks so much for sending that
> schema and XML instance doc that reproduce this problem. That helps
> a lot. I was able to reproduce the problem with those files.
>
> So, I'll look into it. I believe I know what needs to be done.
> There's a simple fix, but, it does not seem like a very pretty one.
>
> When I get a little more time, I'll look into doing a fix that is a
> little more intelligent. It would be more intelligent if we could
> check to see if there are any existing types that have this new
> name and, if so, generate a new type name. I'm not sure whether
> that is doable (for example, whether at that point in the processing
> we know the existing type names) and, if doable, how difficult it
> would be. So ...
>
> more later.
>
> Later ... I believe I have that fix. I need to do more thorough
> testing, and perhaps I should create a unit test for this case and
> other cases of anonymous type definitions. I hope to have a fix to
> send to you tomorrow.
>
> - Dave
>
> >
> > <?xml version="1.0" encoding="utf-8" ?>
> > <xs:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="
> http://www.w3.org/2001/XMLSchema";>
> > <xs:element name="FooList">
> > <xs:complexType>
> > <xs:sequence>
> > <xs:element name="Foo">
> > <xs:complexType>
> > <xs:all>
> > <xs:element name="FooType">
> > <xs:simpleType>
> > <xs:restriction base="xs:string">
> > </xs:restriction>
> > </xs:simpleType>
> > </xs:element>
> > </xs:all>
> > </xs:complexType>
> > </xs:element>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> > </xs:schema>
> >
> > I save this in a local file called foo.xsd and then I generate the
> parser:
> > python ../../venv/bin/generateDS.py -o foo.py foo.xsd
> >
> > Here's a corresponding sample foo.xml file:
> > <?xml version="1.0" encoding="utf-8"?>
> > <FooList>
> > <Foo>
> > <FooType>XPV</FooType>
> > </Foo>
> > </FooList>
> >
> > I try to parse it:
> > python foo.py foo.xml
> >
> > Here's what I get:
> > <?xml version="1.0" ?>
> > <FooList>
> > <Foo>
> > </Foo>
> > </FooList>
> >
> > Notice that the <FooType> sub-element did not get parsed.
> >
> > My guess is that this is a name collision problem. generateDS creates a
> class called FooType for the <Foo> element, so maybe this clashes with the
> <FooType> sub-element. At least, it looks like Foo is being treated like a
> string, when it should be treated like full-fledged element:
> >
> > ...
> > class FooList(GeneratedsSuper):
> > ...
> > def buildChildren(self, child_, node, nodeName_,
> fromsubclass_=False):
> > if nodeName_ == 'Foo':
> > Foo_ = child_.text
> > Foo_ = self.gds_validate_string(Foo_, node, 'Foo')
> > self.Foo = Foo_
> > self.validate_FooType(self.Foo) # validate type FooType
> > ...
> >
> > What do you think?
> >
> > thanks!
> >
> > --S
> >
>
>
> --
>
>
> Dave Kuhlman
> http://www.rexx.com/~dkuhlman
>
--
http://twitter.com/shahafabileah
------------------------------------------------------------------------------
Introducing Performance Central, a new site from SourceForge and
AppDynamics. Performance Central is your source for news, insights,
analysis and resources for efficient Application Performance Management.
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
