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

Reply via email to