#12 simpletype element is not being created as python class

[Omar Garrido Martin]

First of all, sorry since this is my first time on SourgeForge so Im kind of new to repo and I dont even know where should I open Issues.

Second, I want to thank the creator of generateDS for this great tool that you have been developing. It has probe to be very useful for the last days Ive been using it.

I have found a possible problem (probably due to my bad use of the tool) when generating python classes from xsd schemas, in particular Im using the railML2.3 schemas that I will attach so they can be used for testing purposes.

The problem is that some simple types that are correctly recognized by the software someway arent found later on the .py file generated. This only happens with some I will put an example to make it clearer and reproducible.

Within the zip file under schema/genericRailML.xsd we can found the element "tCoordinateList". This element is not found as a class in the .py generated although Ive checked that the genericRailML is being imported (after a few nested imports) when generated.

The code to generate the .py is the following:

generateDS.py -o rail_mL.py schema/railML.xsd

While under the generated python file "rail_ml.py" some references to tCoordinateList can be found, there is no class that represent it.

I dont know if this is an issue or just that Im using the software in a bad way and mayybe I should add some other options when generating the python code.

I would appreciate some help regarding this issue as the tool is great and worked so far, so I would like to avoid having to create some classes manually.

Thanks,

[Dave Kuhlman]

Omar,

Good to hear from you. Thanks for the comments and questions. That
often helps me to learn a bit more about XML schema.

Here are several comments that might be helpful:

1. Your question is about an xs:simpleType. generateDS.py
   generates a Python class for each xs:complexType, but not for
   xs:simpleType.

2. I generated a module from
   railML-2.3-final/schema/infrastructure.xsd. I have a shell script
   that runs the following, but you can use simpler commands for your own
   purposes:

   $ generateDS.py -f -o tmp01sup.py -s tmp01sub.py --super tmp01sup
   --member-specs=dict '--export=write etree validate'
   railML-2.3-final/schema/infrastructure.xsd

If you do that, in the generated Python module, you will find a
class tGeoCoord. It has a member named "coord", whose type is
tCoordinateList (actually, rail:tCoordinateList). tGeoCoord
is defined in railML-2.3-final/schema/infrastructureTypes.xsd and
tCoordinateList is defined in
railML-2.3-final/schema/genericRailML.xsd. generateDS.py uses
those type definitions to generate code that can parse, validate,
and export that member/field. In your generated module, look for
class tGeoCoord and the handling of the coord member in that
class. In particular, look at the build, export, and validate
methods.

So, the upshot is that after generating a module, you will not
find a generated Python class for each xs:simpleType, but you
will find code in the classes that have members of that type that
enables them to parse, validate, and export those member data items.

I hope this is helpful. Please ask if you need more info or help.

Dave

[Omar Garrido Martin]

[Dave Kuhlman]

That seems like a bug to me.

I'm in the middle of work helping someone make some enhancements to
generateDS. Give me a day or two to clean that up. Then I'll
work on this one.

I'm guessing that because coord is define as a tCoordinateList
which is a restriction of tDoubleList which is where it's defined
as a list. Likely, gDS is not smart enough to check the restricted
xs:simpleType and the xs:simpleType that it restricts, etc.

Like I say, give me a couple of days and I'll look into it. I also
need to make sure that the __init__, validate, export, and build
methods that we generate are consistent with each other on handling
lists.

Dave

[Omar Garrido Martin]

Hi Dave,

thats what I though also. Let me know if I can provide any help somehow. Ill wait for an update.

Thanks for your attention.

[Dave Kuhlman]

Omar,

I've implemented a fix. Now, gDS successfully determines that it's
a list type even when it's the xs:simpleType that is being
restricted where it's define as a list. I've also implemented this
fix for other types in addition to the xs:double in your case.

I've also added a unit test that tries to tests these cases.

I've uploaded a new version (v. 2.38.3) containing these fixes to
sourceforge.net and PyPI.

When you try this, could you please let me know whether it
fixes things for you.

And, thank you for your help and for being (I hope) patient with me
on this.

Dave

[Omar Garrido Martin]

Hi Dave,

first thanks for the quick fix, after taking a quick view at the last commit related to this particular issue I was able to "export" the tGeoCoord as needed by doing:

a_three_coord_geoCoord = tGeoCoord(coord="38.2655 38.2655 38.2655")

For me this works as expected since the string gets printed when using the export. But ive noticed that, at least on the export method, there is not any kind of validation in the format of the elements of the list (being xs:double) in this case.

For example these examples:

a_three_coord_geoCoord = tGeoCoord(coord="38.2655 HelloWorld 38.2655 FourthArgumentShouldNotWork")

Will work as is only being taken as a string not any formatting restrictions are being applied to it.

On the other hand Ive tried using iterables, although there doesnt seem to be references to iterables appart from the "validate_tCoordinateList(self, value)" method.

a_three_coord_geoCoord = tGeoCoord(coord=[38.2655, 38.2655, 38.2655])

The list just get converted somehow to a string in the process and the export works but printing something like this:

<rail:geoCoord coord="[38.2655, 38.2655, 38.2655]"/>

In this case:

a_three_coord_geoCoord = tGeoCoord(coord=(38.2655, 38.2655, 38.2655))

the export method simply fails:

    self.geoCoord.export(outfile, level, namespaceprefix_, namespacedef_='', name_='geoCoord', pretty_print=pretty_print)

    self.exportAttributes(outfile, level, already_processed, namespaceprefix_, name_='tGeoCoord')

    outfile.write(' coord=%s' % (quote_attrib(self.coord), ))
    s1 = (isinstance(inStr, BaseStrType_) and inStr or '%s' % inStr)

TypeError: not all arguments converted during string formatting

Ive noticed that in your test it seems to create specific methods on the export to apply formatting like "gds_format_double_list" and "gds_validate_double_list" but I dont know why those are not working on the railML "tCoordinateList"

This issue is not blocking me anymore, but I feel like the solution is still uncomplete, from my ignorance related to gDS. Maybe you would like to have a look using the railML schemas I provided so Ive provided all the info I can on this message. Let me know if I can help you by providing more data.

Thanks for your effort and attention

[Dave Kuhlman]

Omar,

I agree with you that it would be good if gDS generated some support
for validating lists of xs:simpleType. But, I wanted to get
something to you that enabled you to use it. OK, yes I was lazy,
too. So, maybe that validation is an enhancement that I can look
into sometime.

In the meantime, I suppose you will have to do your own checking
when setting the value programmatically.

I'll try to set aside some time for this validation. But, I've got
to clear up a few other things first. Thank you for the suggestion.
When and if I make some progress on this, I'll give you a heads up.

Dave

[Omar Garrido Martin]

Hi Dave,

As I said this is enough for me to keep working.
I just want to let you know about that since I didnt not if you were aware of it, that being said I totally understand that this can be something for the future.

One final time I would like to thank you for your support and gDS library. I think that is the best one out there in python to work with xml schemas ;)

The issue can be considered close for me.