According to http://doc.cloveretl.com/documentation/ … -pane.html:
Field Details
Basic
Nullable
This can be true or false. The default value is true. In such a case, the field value can be null. Otherwise, null values are prohibited and graph fails if null is met.
If nullable is set to false for a string field on the output port of XMLExtract, and the XML field mapped to the field does not exist (or is empty), the graph does not fail.
XML Validation against XSD as of right now is not supported in the XMLExtract, please use a custom Java transformation which can validate XML files against XSD.
This is an intended behavior, the XMLExtract fills in empty string instead of null if null values are not allowed. I personally would suggest that you set nullable to “true” (default value) and to add Reformat after the XMLExtract to check the field(s) for null values.
It would double the disk IO for file read/write to use Java transformation for validation, and XMLExtract for other transformations. It would halve the throughput for intensive XML processing.
It would be good if future XMLExtract could support XSD validation, even if it is just partially (i.e., field exists or not through nullable). That would save a huge effort to use validator (or transform) to check the fields one by one – in my case, over 400 fields over nearly 30 edges! Imagine how messy the graph would be.
Based on our client feedback, our development team are working on improving this feature. It will unfortunately take some time to complete, but it should greatly improve the XML Validation.