Re: [Generateds-users] NameError in buildChildren

Bob Barcklay Fri, 27 Oct 2017 09:16:32 -0700

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 <dkuhl...@davekuhlman.org> 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:

   <xs:element ref="Abc"/>

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:

   <xs:element name="Abc" type="AbcType"/>

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 <module>
   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<https://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd> and the relevant bits are:

<complexType name="KeyInfoType" mixed="true">
<choice maxOccurs="unbounded">
...
<element ref="ds:X509Data"/>
...
<any processContents="lax" namespace="##other"/>

</choice>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
...

<element name="X509Data" type="ds:X509DataType"/>
<complexType name="X509DataType">
<sequence maxOccurs="unbounded">
<choice>
...
</choice>
</sequence>
</complexType>

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
<generateDS.py.patch>

------------------------------------------------------------------------------
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

Re: [Generateds-users] NameError in buildChildren

Reply via email to