Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DTD parsing, CLI, and BaseModel support #17

Closed
Nicholas-Schaub opened this issue Jun 7, 2023 · 1 comment
Closed

DTD parsing, CLI, and BaseModel support #17

Nicholas-Schaub opened this issue Jun 7, 2023 · 1 comment

Comments

@Nicholas-Schaub
Copy link

Excellent library. I was able to successfully generate a a tool for parsing fairly complex XML. There were a few bumps in the road, so I thought I'd give some feedback and see if there are some things you might find useful.

For reference, the library I generated:
https://github.com/nicholas-schaub/pubmed-types

You can see the entire generation process and run it yourself if you're interested, since it uses a nox workflow. You can find it in noxfile.py, and can run it by installing with pip install nox and running from the commandline using nox.

First, dtd support wasn't documented, but I tried running it on a dtd file and to my surprised it worked. However, it wasn't able to properly link mml:math, and it's unclear to me where the issue with this is. I played around with the .mod files and the entity definitions, but I just could not get it to link properly. Fortunately, the other schema I was trying to convert had the same class, so I was able to go in and link to the Math class generated by the other schema. But I had to manually modify the file, as you will see in the noxfile workflow. So I guess my question/comment would be: Is this an issue with the dtd, or is this a quirk of the current implementation because dtd isn't officially supported?

Second, a minor comment: Could you add an input argument to the CLI to ignore a top level folder? A common practice in making Python libraries is to put all source code into a src folder. The reason for this is that this additional layer helps to prevent a local import while testing. However, when I try to generate pydantic classes I get an __init__.py in the src directory that I have to manually remove.

Third, could you support pydantic.BaseModel instead of just pydantic.dataclass? I ask because BaseModel has some useful serialization/deserialization functionality that the dataclass doesn't have. It's obviously still possible to get the same functionality, but it's more boilerplate work.

I realize this is a lot. I'm happy to close this issue and submit issues for each topic to make them more granular.

@tefra
Copy link
Owner

tefra commented Apr 1, 2024

see #23 for pydantic v2, for the other issues please open tickets in the xsdata repo please

@tefra tefra closed this as completed Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants