-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Property] Clarify relationship between "required field" and "blanks allowed" in OED Spec #181
Comments
As discussed, this would be a breaking change and can be considered for OED v4. In particular; Location file: Reinsurance info file: RiskLevel (required field) will not allowed to be blank. Currently a blank means that there are no risk terms to apply, which is valid for some Reinsurance Types. We would need to introduce a non-blank value meaning no risk terms. e.g. 'NRT'. (char(3)) This would replace blank in the list in 'OtherValues'. LocPopNumber is the only optional field which may not be blank. For consistency with all the other optional fields, this would be relaxed to allow blanks, with a default value specified (0?) |
Follow up proposal:
*RiskLevel only needs to be specified if the reinsurance files contain ReinsType = Surplus Share (CededPercent is present), or there are risk terms in the info file (RiskAttachment or RiskLimit is present). If none of these three fields are present, then there are no risk level terms and RiskLevel can be assumed to be blank for all contracts. The end result will be a cleaner spec and no breaking changes other than the format of the OED specification file. It also clarifies the relationship between RiskLevel and RiskAttachment, RiskLimit and CededPercent for reinsurance. Note 1: TIV fields are generally not required for broader use cases of OED, e.g. development / humanitarian sector. At least one TIV field is required for catastrophe modelling of property (i.e Oasis use cases), but this can be added as an Oasis-specific validation rule on top of OED validation. Note 2: the specification file will change in OED v4 anyway due to the integration of Cyber and Liability fields. |
I think the proposals look good. It should be much cleaner and less liable to interpretation. |
Final proposal following TWG call this morning
Outstanding: |
Conditionally required tab codes |
Latest Joh's proposal from May 23 looks fine. |
Description
It has been suggested that having both "required field" and "blanks allowed" columns in the OED spec is counter intuitive, confusing and can lead to different interpretations of the specification.
Reasons for change
Validation software can make inferences about what the data should look like, which can be different between applications. Oasis itself applies logic to, say, required fields that are blank (where it applies the default value).
Ideally the spec should be clear enough that inferences don't need to be made. It's proposed that all required fields should not allow blanks, and all optional fields should allow blanks. But then the question is whether we need two columns in the specification
Required fields not allowing blanks should not need a default value (because they will always be there)
Scope of change
Impact of change
Changing the specification to have only one column will cause validation software that uses the specification to break.
Aligning the logic so that all required fields do not allow blanks (and vice versa) will not break the validation but previously valid OED files might no longer be valid.
Fields to be discussed
The text was updated successfully, but these errors were encountered: