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 <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 > > <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><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"/> > >> <!-- (1,1) elements from (0,unbounded) namespaces --> > >> </choice> > >> <attribute name="Id" type="ID" use="optional"/> > >> </complexType> > >> ... > >> <!-- Start X509Data --> > >> <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 > >> > > 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