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
I do understand that content validation is not performed based on your documentation, not to mention that unknown elements are simply dropped.
Is it possible to add validation so that if for instance, JSON or XML is parsed that contains elements that do not match the given message type and version, that a suitable error can be thrown?
For instance, a JSON ISO-20022 message whereby the field names started with capital letters was not thrown out, but the fields simply thrown away. It would be beneficial that when invalid data is sent, that a suitable error is thrown back so that integrators can assess and correct the error. This will ensure that good structured data is sent and that errors are not swept under the carpet.
The text was updated successfully, but these errors were encountered:
Thanks for the feedback, however for several reasons this not within the scope of the library.
I suggest you get the corresponding XSD schemas and you apply a validation of the XML payload against the schema yourself. As a decoupled process of the unmarshalling into the model.
The model is intended to facilitate consumption of the XML data from plain Java DTOs. And to do enrichment or modification of the content before marshaling that back into XML.
I do understand that content validation is not performed based on your documentation, not to mention that unknown elements are simply dropped.
Is it possible to add validation so that if for instance, JSON or XML is parsed that contains elements that do not match the given message type and version, that a suitable error can be thrown?
For instance, a JSON ISO-20022 message whereby the field names started with capital letters was not thrown out, but the fields simply thrown away. It would be beneficial that when invalid data is sent, that a suitable error is thrown back so that integrators can assess and correct the error. This will ensure that good structured data is sent and that errors are not swept under the carpet.
The text was updated successfully, but these errors were encountered: