On Thu, Jul 13, 2017 at 8:28 PM, Dave Kuhlman <dkuhl...@davekuhlman.org>
wrote:
> Olof,
>
> [Sorry for the wordiness below. Writing it out helps me think it
> through.]
>
>
Hi Dave,
Thanks for the quick reply. Wordiness is good. I don't know much of the
world of xsd, so it's great to get some context
> 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?
>
>
Yes, viewRef is one of the duplicated ones.I get six different classes in
the generated python code (viewRefType,viewRefType3, viewRefType4,
viewRefType6, viewRefType10, viewRefType15), and they are all identical.
> 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.
>
>
I see what you mean here. Looking through the xsd sources, there really are
six different definitions of viewRef, and they all look identical. Without
knowing anything about xsd, I assume there should ideally only be one, and
all other should refer to this.
Question: Is this really a problem for you, or are you suggesting an
> improvement?
>
> I'm not sure actually. My idea is to do a one-time conversion, and use
this as a base for a python library for reading and writing IP-XACT files.
I already have a library where I have manually implemented parts of the
schema with some yaml and dynamic class creation trickery (
https://github.com/olofk/ipyxact), but I feel it would be much better to
use an existing solution such as generateDS. With that said, it will be a
problem if my users are expected to know that they need to create objects
of type viewRefType3, viewRefType6 etc, depending on where in the tree the
object should go. But I also haven't looked closely enough at the generated
generateDS classes to understand if the class names are hidden as
implementation details.
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.
>
>
In this case, I'm ready to modify the xsd sources to make the python code
better, but I honestly don't understand enough xsd to know how to fix it.
Would you be able to find the time to give me an example on what to change?
Another, even hackier solution that I thought of was to write a small
script that detected and removed identical classes after the python code
was generated. Though ugly, it is doable as I'm expecting to store the
generated python files, and only update if the schemas change (which they
shouldn't)
> I'll study this a bit more and will report back later.
>
> Hope this helps. Sorry, again, for being so verbose.
>
>
Many thanks. Help and verbosity is much appreciated
> Dave
>
>
Cheers,
Olof
>
> 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
