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"/>
> <!-- (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
>
> ------------------------------------------------------------------------------
> 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():
------------------------------------------------------------------------------
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
