Since, apparently, different banks want different alignment we might need to find a way to provide an XSD to the X937 record system to allow for overrides of certain things.
My concern with going full XSD to define the entire records is it could make it difficult to get property values from these "unknown" records. As an example, in the Bundle Control Record, we need to add up all the item totals from the records in the bundle. I suppose we could try to find a different way to get these control values rather than from the generated records themselves. Another example is when we subclass a method and need to override property values because of specific needs for the bank.
So far, I don't think I've seen any banks that completely change the field structure or field type. I've seen some banks say a field is "number" and some banks say the same field is "number or blank", but I don't think those difference would be a problem for "structure" of the class properties. So maybe we can define interfaces for the most basic record field structure (e.g. is a field some form of string, integer, decimal, etc.) and then use XSD to define the specifics about alignment, required or not, zero-padded vs whitespace-padded, etc.
Since, apparently, different banks want different alignment we might need to find a way to provide an XSD to the X937 record system to allow for overrides of certain things.
My concern with going full XSD to define the entire records is it could make it difficult to get property values from these "unknown" records. As an example, in the Bundle Control Record, we need to add up all the item totals from the records in the bundle. I suppose we could try to find a different way to get these control values rather than from the generated records themselves. Another example is when we subclass a method and need to override property values because of specific needs for the bank.
So far, I don't think I've seen any banks that completely change the field structure or field type. I've seen some banks say a field is "number" and some banks say the same field is "number or blank", but I don't think those difference would be a problem for "structure" of the class properties. So maybe we can define interfaces for the most basic record field structure (e.g. is a field some form of string, integer, decimal, etc.) and then use XSD to define the specifics about alignment, required or not, zero-padded vs whitespace-padded, etc.