Re: [Generateds-users] NameError in buildChildren

[Olof Kindgren]

Hi Dave,

Right about the same time as you provided a fix I got pulled away on other
projects. Just wanted to let you know that the fix works fine with a
recently installed version of generateDS. Many thanks. Got a few other
things, but I'll start new threads for them

Cheers,
Olof


On Fri, Oct 27, 2017 at 8:18 PM, Dave Kuhlman 
wrote:

> Bob,
>
> Oh, nuts.  I should have remembered to check on that.  I apologize.
>
> Thank you for catching and fixing this.  I've applied your patch in
> my repository.
>
> Dave
>
> On Thu, Oct 26, 2017 at 05:57:39PM -0700, Bob Barcklay wrote:
> > Hi Dave,
> >
> > I tried out the patch.  It did catch and correct one of the
> > element/type issues but not others that I was encountering.  I did
> > some tracing and found that the elements in question were not being
> > processed by the patched code in the method generateBuildStandard_1.
> > They were appearing in generateBuildMixed_1 so I followed the
> > pattern from your patch making a similar change in that method.
> > That has solved my problem.  I can’t be sure that I haven’t
> > introduced new problems so please take a look at the attached patch
> > and let me know what you think.  It includes both your original
> > changes and the changes I made to generateBuildMixed_1.
> >
> > -Bob
> >
> >
> >
> >
> > > On Oct 25, 2017, at 8:55 PM, Dave Kuhlman 
> wrote:
> > >
> > > Bob (and Olof),
> > >
> > > I believe that I've fixed this one.
> > >
> > > The rest of this message is just notes I wrote while stumbling
> > > toward what I hope is a solution.
> > >
> > > The fix is at https://bitbucket.org/dkuhlman/generateds <
> https://bitbucket.org/dkuhlman/generateds>
> > >
> > > And, a patch file is attached, in case that is more convenient.
> > >
> > > I've found one suspicious result so far in my testing.  But, it's in
> > > the export to etree code, which is rarely used.  I'll look into that
> > > tomorrow.
> > >
> > > [And Dave continues to mutter to himself, mostly.]
> > >
> > > OK, so here is what generateDS.py believes (because I wrote it to
> > > believe it): When, in an xs:complexType, you use:
> > >
> > >
> > >
> > > it means that you are defining a child element whose name (the
> > > element tag) and type (a complexType) are the same, in this case
> > > "Abc".
> > >
> > > But, in your schema, "Abc" refers to a global xs:element, rather
> > > than a xs:complexType, and the type of that element is different, in
> > > this case "AbcType".
> > >
> > > You could fix this by changing the above child definition to:
> > >
> > >
> > >
> > > But, I just now did a quick search, and you should not have to make
> > > that change.  Your schema is correct in this respect.
> > >
> > > So, that means that, when you use the above child definition,
> > > generateDS.py should look up the global definition, and if it is an
> > > xs:element (rather than an xs:complexType), then generateDS.py
> > > should look up its type and use it.
> > >
> > > Give me a while to figure out how to do that. ...
> > >
> > > I just checked.  The information is there to enable us to do that.
> > > Now, I just need to figure out where to make the change.
> > >
> > > By the way, yesterday, I said that I thought that this issue seems
> > > similar to an issue reported a couple of days ago.  That one was
> > > reported by Olof Kindgren.  After studying the problem you've
> > > reported and then looking at the problem reported by Olof in the
> > > light of what I learned, it really does seem that these two problems
> > > have a common solution.  I'll have to study that a bit more.
> > >
> > > More later.
> > >
> > > Dave
> > >
> > > On Mon, Oct 23, 2017 at 05:07:20PM -0700, Bob Barcklay wrote:
> > >> Hi,
> > >>
> > >> I am using generateDS to parse an XML Signature.  When I attempt to
> parse the signature XML, I encounter an error in a buildChildren method:
> > >>
> > >> $ python xmldsig.py sig.xml
> > >> Traceback (most recent call last):
> > >>  File "xmldsig.py", line 3511, in 
> > >>main()
> > >>  File "xmldsig.py", line 3504, in main
> > >>parse(args[0])
> > >>  File "xmldsig.py", line 3420, in parse
> > >>rootObj.build(rootNode)
> > >>  File "xmldsig.py", line 796, in build
> > >>self.buildChildren(child, node, nodeName_)
> > >>  File "xmldsig.py", line 816, in buildChildren
> > >>obj_.build(child_)
> > >>  File "xmldsig.py", line 1845, in build
> > >>self.buildChildren(child, node, nodeName_)
> > >>  File "xmldsig.py", line 1879, in buildChildren
> > >>obj_ = X509Data.factory()
> > >> NameError: name 'X509Data' is not defined
> > >>
> > >> It appears that the generated code is using the element name
> (‘X509Data’) when it should be using the type/class name (‘X509DataType’).
> If I regenerate the code with this switch:
> > >>
> > >> $generateDS —fix-type-names “X509DataType:X509Data” xmldsig.xsd
> > >>
> > >> It parses correctly. The schema is here:  

Re: [Generateds-users] NameError in buildChildren

[Dave Kuhlman]

Bob,

Oh, nuts.  I should have remembered to check on that.  I apologize.

Thank you for catching and fixing this.  I've applied your patch in
my repository.

Dave

On Thu, Oct 26, 2017 at 05:57:39PM -0700, Bob Barcklay wrote:
> Hi Dave,
> 
> I tried out the patch.  It did catch and correct one of the
> element/type issues but not others that I was encountering.  I did
> some tracing and found that the elements in question were not being
> processed by the patched code in the method generateBuildStandard_1.
> They were appearing in generateBuildMixed_1 so I followed the
> pattern from your patch making a similar change in that method.
> That has solved my problem.  I can’t be sure that I haven’t
> introduced new problems so please take a look at the attached patch
> and let me know what you think.  It includes both your original
> changes and the changes I made to generateBuildMixed_1.
> 
> -Bob
> 
> 
> 
> 
> > On Oct 25, 2017, at 8:55 PM, Dave Kuhlman  wrote:
> > 
> > Bob (and Olof),
> > 
> > I believe that I've fixed this one.
> > 
> > The rest of this message is just notes I wrote while stumbling
> > toward what I hope is a solution.
> > 
> > The fix is at https://bitbucket.org/dkuhlman/generateds 
> > 
> > 
> > And, a patch file is attached, in case that is more convenient.
> > 
> > I've found one suspicious result so far in my testing.  But, it's in
> > the export to etree code, which is rarely used.  I'll look into that
> > tomorrow.
> > 
> > [And Dave continues to mutter to himself, mostly.]
> > 
> > OK, so here is what generateDS.py believes (because I wrote it to
> > believe it): When, in an xs:complexType, you use:
> > 
> >
> > 
> > it means that you are defining a child element whose name (the
> > element tag) and type (a complexType) are the same, in this case
> > "Abc".
> > 
> > But, in your schema, "Abc" refers to a global xs:element, rather
> > than a xs:complexType, and the type of that element is different, in
> > this case "AbcType".
> > 
> > You could fix this by changing the above child definition to:
> > 
> >
> > 
> > But, I just now did a quick search, and you should not have to make
> > that change.  Your schema is correct in this respect.
> > 
> > So, that means that, when you use the above child definition,
> > generateDS.py should look up the global definition, and if it is an
> > xs:element (rather than an xs:complexType), then generateDS.py
> > should look up its type and use it.
> > 
> > Give me a while to figure out how to do that. ...
> > 
> > I just checked.  The information is there to enable us to do that.
> > Now, I just need to figure out where to make the change.
> > 
> > By the way, yesterday, I said that I thought that this issue seems
> > similar to an issue reported a couple of days ago.  That one was
> > reported by Olof Kindgren.  After studying the problem you've
> > reported and then looking at the problem reported by Olof in the
> > light of what I learned, it really does seem that these two problems
> > have a common solution.  I'll have to study that a bit more.
> > 
> > More later.
> > 
> > Dave
> > 
> > On Mon, Oct 23, 2017 at 05:07:20PM -0700, Bob Barcklay wrote:
> >> Hi,
> >> 
> >> I am using generateDS to parse an XML Signature.  When I attempt to parse 
> >> the signature XML, I encounter an error in a buildChildren method:
> >> 
> >> $ python xmldsig.py sig.xml
> >> Traceback (most recent call last):
> >>  File "xmldsig.py", line 3511, in 
> >>main()
> >>  File "xmldsig.py", line 3504, in main
> >>parse(args[0])
> >>  File "xmldsig.py", line 3420, in parse
> >>rootObj.build(rootNode)
> >>  File "xmldsig.py", line 796, in build
> >>self.buildChildren(child, node, nodeName_)
> >>  File "xmldsig.py", line 816, in buildChildren
> >>obj_.build(child_)
> >>  File "xmldsig.py", line 1845, in build
> >>self.buildChildren(child, node, nodeName_)
> >>  File "xmldsig.py", line 1879, in buildChildren
> >>obj_ = X509Data.factory()
> >> NameError: name 'X509Data' is not defined
> >> 
> >> It appears that the generated code is using the element name (‘X509Data’) 
> >> when it should be using the type/class name (‘X509DataType’).  If I 
> >> regenerate the code with this switch:
> >> 
> >> $generateDS —fix-type-names “X509DataType:X509Data” xmldsig.xsd
> >> 
> >> It parses correctly. The schema is here:  
> >> https://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd
> >>  
> >>  >>  
> >> >
> >>  and the relevant bits are:
> >> 
> >> 
> >> 
> >> 
> >> ...
> >> 
> >> ...
> >> 
> >> 
> >> 
> >> 
> >> 
> >> ...
> >> 
> >> 
> >> 
> >> 
> >> 
> >> ...
> >> 
> >> 
> >> 
> >> 
> >> I don’t understand why the generated 

Re: [Generateds-users] NameError in buildChildren

[Bob Barcklay]

Hi Dave,I tried out the patch.  It did catch and correct one of the element/type issues but not others that I was encountering.  I did some tracing and found that the elements in question were not being processed by the patched code in the method generateBuildStandard_1. They were appearing in generateBuildMixed_1 so I followed the pattern from your patch making a similar change in that method.  That has solved my problem.  I can’t be sure that I haven’t introduced new problems so please take a look at the attached patch and let me know what you think.  It includes both your original changes and the changes I made to generateBuildMixed_1.-Bob

Update_child_type_in_generateBuildMixed_1.patch
Description: Binary data

On Oct 25, 2017, at 8:55 PM, Dave Kuhlman  wrote:Bob (and Olof),I believe that I've fixed this one.The rest of this message is just notes I wrote while stumblingtoward what I hope is a solution.The fix is at https://bitbucket.org/dkuhlman/generatedsAnd, a patch file is attached, in case that is more convenient.I've found one suspicious result so far in my testing.  But, it's inthe export to etree code, which is rarely used.  I'll look into thattomorrow.[And Dave continues to mutter to himself, mostly.]OK, so here is what generateDS.py believes (because I wrote it tobelieve it): When, in an xs:complexType, you use:   it means that you are defining a child element whose name (theelement tag) and type (a complexType) are the same, in this case"Abc".But, in your schema, "Abc" refers to a global xs:element, ratherthan a xs:complexType, and the type of that element is different, inthis case "AbcType".You could fix this by changing the above child definition to:   But, I just now did a quick search, and you should not have to makethat change.  Your schema is correct in this respect.So, that means that, when you use the above child definition,generateDS.py should look up the global definition, and if it is anxs:element (rather than an xs:complexType), then generateDS.pyshould look up its type and use it.Give me a while to figure out how to do that. ...I just checked.  The information is there to enable us to do that.Now, I just need to figure out where to make the change.By the way, yesterday, I said that I thought that this issue seemssimilar to an issue reported a couple of days ago.  That one wasreported by Olof Kindgren.  After studying the problem you'vereported and then looking at the problem reported by Olof in thelight of what I learned, it really does seem that these two problemshave a common solution.  I'll have to study that a bit more.More later.DaveOn Mon, Oct 23, 2017 at 05:07:20PM -0700, Bob Barcklay wrote:Hi,I am using generateDS to parse an XML Signature.  When I attempt to parse the signature XML, I encounter an error in a buildChildren method:$ python xmldsig.py sig.xmlTraceback (most recent call last): File "xmldsig.py", line 3511, in    main() File "xmldsig.py", line 3504, in main   parse(args[0]) File "xmldsig.py", line 3420, in parse   rootObj.build(rootNode) File "xmldsig.py", line 796, in build   self.buildChildren(child, node, nodeName_) File "xmldsig.py", line 816, in buildChildren   obj_.build(child_) File "xmldsig.py", line 1845, in build   self.buildChildren(child, node, nodeName_) File "xmldsig.py", line 1879, in buildChildren   obj_ = X509Data.factory()NameError: name 'X509Data' is not definedIt appears that the generated code is using the element name (‘X509Data’) when it should be using the type/class name (‘X509DataType’).  If I regenerate the code with this switch:$generateDS —fix-type-names “X509DataType:X509Data” xmldsig.xsdIt parses correctly. The schema is here:  https://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd and the relevant bits are:I don’t understand why the generated code is calling X509Data.factory() instead of X509DataType.factory().  X509DataType is the name of the class in the generated py file.Is this a bug or is there something unusual in the XSD that causes this?  Is the —fix-type-names switch a proper work around?Thanks in advance for any help.-Bob--Check out the vibrant tech community on one of the world's mostengaging tech sites, Slashdot.org! http://sdm.link/slashdot___generateds-users mailing listgenerateds-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/generateds-users-- Dave Kuhlmanhttp://www.davekuhlman.org--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
generateds-users mailing list
generateds-users@lists.sourceforge.net

Re: [Generateds-users] NameError in buildChildren

[Dave Kuhlman]

Bob (and Olof),

I believe that I've fixed this one.

The rest of this message is just notes I wrote while stumbling
toward what I hope is a solution.

The fix is at https://bitbucket.org/dkuhlman/generateds

And, a patch file is attached, in case that is more convenient.

I've found one suspicious result so far in my testing.  But, it's in
the export to etree code, which is rarely used.  I'll look into that
tomorrow.

[And Dave continues to mutter to himself, mostly.]

OK, so here is what generateDS.py believes (because I wrote it to
believe it): When, in an xs:complexType, you use:



it means that you are defining a child element whose name (the
element tag) and type (a complexType) are the same, in this case
"Abc".

But, in your schema, "Abc" refers to a global xs:element, rather
than a xs:complexType, and the type of that element is different, in
this case "AbcType".

You could fix this by changing the above child definition to:



But, I just now did a quick search, and you should not have to make
that change.  Your schema is correct in this respect.

So, that means that, when you use the above child definition,
generateDS.py should look up the global definition, and if it is an
xs:element (rather than an xs:complexType), then generateDS.py
should look up its type and use it.

Give me a while to figure out how to do that. ...

I just checked.  The information is there to enable us to do that.
Now, I just need to figure out where to make the change.

By the way, yesterday, I said that I thought that this issue seems
similar to an issue reported a couple of days ago.  That one was
reported by Olof Kindgren.  After studying the problem you've
reported and then looking at the problem reported by Olof in the
light of what I learned, it really does seem that these two problems
have a common solution.  I'll have to study that a bit more.

More later.

Dave

On Mon, Oct 23, 2017 at 05:07:20PM -0700, Bob Barcklay wrote:
> Hi,
> 
> I am using generateDS to parse an XML Signature.  When I attempt to parse the 
> signature XML, I encounter an error in a buildChildren method:
> 
> $ python xmldsig.py sig.xml
> Traceback (most recent call last):
>   File "xmldsig.py", line 3511, in 
> main()
>   File "xmldsig.py", line 3504, in main
> parse(args[0])
>   File "xmldsig.py", line 3420, in parse
> rootObj.build(rootNode)
>   File "xmldsig.py", line 796, in build
> self.buildChildren(child, node, nodeName_)
>   File "xmldsig.py", line 816, in buildChildren
> obj_.build(child_)
>   File "xmldsig.py", line 1845, in build
> self.buildChildren(child, node, nodeName_)
>   File "xmldsig.py", line 1879, in buildChildren
> obj_ = X509Data.factory()
> NameError: name 'X509Data' is not defined
> 
> It appears that the generated code is using the element name (‘X509Data’) 
> when it should be using the type/class name (‘X509DataType’).  If I 
> regenerate the code with this switch:
> 
> $generateDS —fix-type-names “X509DataType:X509Data” xmldsig.xsd
> 
> It parses correctly. The schema is here:  
> https://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd 
> 
>  and the relevant bits are:
> 
> 
> 
> 
> ...
> 
> ...
> 
> 
> 
> 
> 
> ...
> 
> 
> 
> 
> 
> ...
> 
> 
> 
> 
> I don’t understand why the generated code is calling X509Data.factory() 
> instead of X509DataType.factory().  X509DataType is the name of the class in 
> the generated py file.
> 
> Is this a bug or is there something unusual in the XSD that causes this?  Is 
> the —fix-type-names switch a proper work around?
> 
> Thanks in advance for any help.
> 
> -Bob
> 

> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> ___
> generateds-users mailing list
> generateds-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/generateds-users


-- 

Dave Kuhlman
http://www.davekuhlman.org
diff -r dfcb8c7523dc -r f2f122c25bac generateDS.py
--- a/generateDS.py Tue Oct 17 16:05:30 2017 -0700
+++ b/generateDS.py Wed Oct 25 20:44:48 2017 -0700
@@ -227,7 +227,7 @@
 # Do not modify the following VERSION comments.
 # Used by updateversion.py.
 ##VERSION##
-VERSION = '2.28c'
+VERSION = '2.28d'
 ##VERSION##
 
 if sys.version_info.major == 2:
@@ -3795,6 +3795,10 @@
 type_element = None
 abstract_child = False
 type_name = child.getAttrs().get('type')
+elementDef = ElementDict.get(name)
+if elementDef is not None:
+if elementDef.getName() != elementDef.getType():
+type_name = elementDef.getType()
 if type_name:
 type_element = ElementDict.get(type_name)
 if type_element and type_element.isAbstract():

Re: [Generateds-users] NameError in buildChildren

[Dave Kuhlman]

Bob,

Thanks for this report.  I have not had time to look at this one
yet, but just today I've been working on an issue that seems
similar.  I won't know whether they're related until I've looked at
your schema.

Give me a day or two to snoop.

Dave

On Mon, Oct 23, 2017 at 05:07:20PM -0700, Bob Barcklay wrote:
>Hi,
>I am using generateDS to parse an XML Signature.  When I attempt to parse
>the signature XML, I encounter an error in a buildChildren method:
>$ python xmldsig.py sig.xml
>Traceback (most recent call last):
>  File "xmldsig.py", line 3511, in 
>main()
>  File "xmldsig.py", line 3504, in main
>parse(args[0])
>  File "xmldsig.py", line 3420, in parse
>rootObj.build(rootNode)
>  File "xmldsig.py", line 796, in build
>self.buildChildren(child, node, nodeName_)
>  File "xmldsig.py", line 816, in buildChildren
>obj_.build(child_)
>  File "xmldsig.py", line 1845, in build
>self.buildChildren(child, node, nodeName_)
>  File "xmldsig.py", line 1879, in buildChildren
>obj_ = X509Data.factory()
>NameError: name 'X509Data' is not defined
>It appears that the generated code is using the element name
>(â**X509Dataâ**) when it should be using the type/class name
>(â**X509DataTypeâ**).  If I regenerate the code with this switch:
>$generateDS â**fix-type-names â**X509DataType:X509Dataâ** xmldsig.xsd
>It parses correctly. The schema is here:
> 
> https://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd 
> and
>the relevant bits are:
>
>
>...
>
>...
>
>
>
>
>
>...
>
>
>
>
>
>...
>
>
>
>I donâ**t understand why the generated code is calling X509Data.factory()
>instead of X509DataType.factory().  X509DataType is the name of the class
>in the generated py file.
>Is this a bug or is there something unusual in the XSD that causes this?
> Is the â**fix-type-names switch a proper work around?
>Thanks in advance for any help.
>-Bob

> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> ___
> generateds-users mailing list
> generateds-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/generateds-users


-- 

Dave Kuhlman
http://www.davekuhlman.org

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users