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