You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As per pabigot/pyxb#100, pyxb is marked as EOL pending anyone else offering to maintain it, and being accepted as maintainer. This project is completely dependent on pyxb right now, so non-maintenance could be a significant risk.
For an example of a challenge associated with non-maintenance, pabigot/pyxb#123 reveals that pyxb has a problem resulting from a breaking change in Python 3.8, which will also affect this project.
Is there an alternative we can adopt?
The text was updated successfully, but these errors were encountered:
Quick research suggests some alternatives, without having considered the overall impact of any change:
xsData (repo) is actively maintained and claims good XML Schema 1.0 and 1.1 support. MIT licence.
generateDS (repo) is actively maintained and MIT licence, but does not make any particular claim to full conformance or testing against any XML Schema version.
Just use Python's native ElementTree and write the rest ourselves. Maybe protect against various XML vulnerabilities by using defusedxml
Successfully switched to renalreg/PyXB-X in the BBC fork, which is also now up to Python3.11 (but doesn't support all functionality yet, for example the autobahn/twisted tests do not pass) - suggest doing the same here.
As per pabigot/pyxb#100, pyxb is marked as EOL pending anyone else offering to maintain it, and being accepted as maintainer. This project is completely dependent on pyxb right now, so non-maintenance could be a significant risk.
For an example of a challenge associated with non-maintenance, pabigot/pyxb#123 reveals that pyxb has a problem resulting from a breaking change in Python 3.8, which will also affect this project.
The text was updated successfully, but these errors were encountered: