Olof,
[Sorry for the wordiness below. Writing it out helps me think it
through.]
Still groping with and studying this one, but ...
I believe that the issue occurs when we have anonymous
xs:complexType definition, that is, an xs:complexType that is used
in place. For example, it is nested in another xs:complexType and
used to declare one of the outer xs:complexType's members.
Because we need to generate a Python class for that anonymous
xs:complexType and because Python classes must have a name, we
effectively raise that anonymous xs:complexType to top-level and
give it a name. This is done in process_includes.py, by the way.
If you look in port.xsd, you will see two members declared as:
<xs:element name="typeName" minOccurs="0">
and:
<xs:element name="typeName">
which are each declared with a type that is an anonymous
xs:complexType.
In this case, there is a difference in the two xs:complexType
definitions. But, as you can imagine, had someone copied and pasted
the same xs:complexType, you'd end up with two different classes
with different names, but with the same content.
I believe that an example of two that are exactly the same are the
declarations of element/member "viewRef" in commonStructures.xsd.
Are these the duplicates that you are talking about?
It would be an interesting problem, I suppose, to try to write a
function which, given two Lxml xs:complexType nodes, would try to
determine whether there were any differences. Note that we'd even
need to worry about whether a difference in the
annotation/documentation, which we use to generate the doc string on
the Python class, counted as a real difference.
Question: Is this really a problem for you, or are you suggesting an
improvement?
Note that you could "fix" this yourself by modifying the schemas so
that these anonymous complex types had names and so that any
duplicates were collapsed into a single named xs:complexType. That
requires modifying the schema, and I can understand that you might
not want to do that.
I'll study this a bit more and will report back later.
Hope this helps. Sorry, again, for being so verbose.
Dave
On Thu, Jul 13, 2017 at 11:51:01AM +0200, Olof Kindgren wrote:
> Hi Dave,
>
> I'm trying to parse a set of xsd files into a python structure with
> generateDS. Couldn't find a bug tracker so I'm writing you a mail instead.
>
> The xsd files are parsed just fine, but I end up with a bunch of identical
> classes with a numeric suffix.
> Looking at the generated python code, these classes are identical, except
> for the class name, and I would have expected them to use the same class
> instead of creating new variations.
>
> I've tracked this down to the unique_name function in process_includes.py,
> but I haven't really understood what I can do to get around this. For
> reference, these are the xsd files I'm using (starting with index.xsd)
> http://www.accellera.org/XMLSchema/IPXACT/1685-2014/
>
> Is there a command line option I'm missing for reusing type names, or do
> you have an idea of what I would need to change to make it work?
>
> Thanks,
> Olof
--
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
