Closed henryk closed 5 years ago
In general, I think this is a good idea. This should not be to hard, as we already do it in our test suite and we already ship the XSDs in this repository: https://github.com/raphaelm/python-sepaxml/blob/master/tests/transfer/test_endtoendid.py#L132
However, there are a couple of things to consider, and reasons why I didn't implement it so far:
lxml
(which is an annoying dependency since you need to compile it yourself for ~minutes on many systems) whereas this package currently does not have any dependenciesAs a anecdata point, I was just bitten by an ü in a <Nm>
tag, which lead to my bank not accepting the XML (even though the XSD validated, as far as I can tell).
There's no need to make it required so that could alleviate some issues :)
As for the lxml dependency, you could depend on xmlschema instead. It's pure python: https://pypi.org/project/xmlschema/
Also, if you make it an optional install (i.e. pip install sepaxml
vs pip install sepaxml[validation]
) that shouldn't be a problem in any case.
Would be great to include the pain...xsd schema files and include schema validation in the generation process (maybe make it opt-out so that people who know they're doing everything right can disable it if they want to generate thousands of messages per second and think validation is slowing them down).
Background: IMHO the library should prevent the library user (the programmer) from doing obviously incorrect things/producing invalid messages. On my first attempt I violated the XSD constraints for the mandate_id, and the bank response was a simple "SEPA-Nachrichtenformat ungültig.". Builtin schema validation (I hope it's merely adding a python dependency and adding a function call) could prevent this.