Editing the model
When editing DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data., it's essential to go through the following modelling checklist:
- DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. version: use the latest available development version
- Syntax: no syntax warnings or errors
- Compilation: model compiles ok with no static compilation errors
- Testing: all translate regression tests expectations for mapping, validation and qualification maintained or improved. Additional test samples may be needed if use-case is not covered by existing samples.
- Namespace: all model components positioned in the correct namespace
- Descriptions: all model components have descriptions
The following sections detail that checklist. When using the RosettaRosetta REGnosys’s proprietary platform used as an execution engine for DRR. Design web application to edit the model, the Contributor should also refer to the Rosetta Design Guide.
DRR version
To the extent possible it is recommended that the Contributor keeps working with a version of DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. that is as close as possible to the latest to minimise the risk of backward compatibility.
Please refer to the Source Control Integration Guide for more information.
Syntax
The model is represented in the Rune DSLRune DSL The domain-specific language built on Java that DRR uses for its logic. syntax. All syntax warnings and errors must be resolved to have a valid model before contributing any changes. For further guidance about features of the syntax, please refer to the Rune DSL Documentation.
In RosettaRosetta REGnosys’s proprietary platform used as an execution engine for DRR. Design, that syntax is automatically checked live as the user edits the model, as described in the Rosetta Design Content Assist Guide.
Compilation
Normally, once the model is syntactically correctly edited, valid code is being auto-generated and compiled. However, certain model changes can cause compilation errors when changes conflict with static code (e.g. certain mapper implementations).
The RosettaRosetta REGnosys’s proprietary platform used as an execution engine for DRR. support team can help resolve these errors before the changes are contributed. In most cases you will be able to contact the team via the In-App chat. If the support team identifies that significant work may be required to resolve these errors, they will notify the Contributor who should then contact DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. reviewer originally appointed for the proposed change and/or DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. Owners. The latter will be able to assist in the resolution of the issues.
For more information about auto-compilation using the RosettaRosetta REGnosys’s proprietary platform used as an execution engine for DRR. DSLDSL Domain-Specific Language – a programming language for a narrow purpose e.g. for financial regulatory reporting., please refer to the Rosetta Auto Compilation Guide.
Testing
DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. has adopted a test-driven development approach that maps model components to existing sample data (e.g., FpMLFpML Financial Products Markup Language documents or other existing standards). Mappings are specified in DRRDRR Digital Regulatory Reporting. An industry‑developed, machine‑executable interpretation of regulatory rules that produces consistent, transparent and fully traceable reporting outputs from standardised CDM data. and the sample data are collected into a Test Pack. Each new model version is regression-tested using those mappings to translate the sample data in the Test Pack and then comparing against the expected number of mapped data points, validation and qualification results.
When using RosettaRosetta REGnosys’s proprietary platform used as an execution engine for DRR. to edit the model, contributors are invited to test their model changes live against the Test Pack using the RosettaRosetta REGnosys’s proprietary platform used as an execution engine for DRR. Translate application, referring to the Rosetta Translate Guide. When editing existing model components, the corresponding synonyms should be updated to maintain or improve existing mapping levels. When adding new model components, new sample data and corresponding synonym mappings should also be provided so the new use-case can be added to the set of regression tests.
Please refer to the Mapping Guide for details about the synonym mapping syntax.
Namespace
All model components should be positioned appropriately in the existing namespace hierarchy. If the proposed contribution includes changes to the namespace hierarchy, those changes should be justified and documented. Any new namespace should have an associated description, and be imported where required.
Please refer to the namespace documentation section for more details.
Descriptions
All model components (e.g. types, attributes, conditions, functions etc.) should be specified with descriptions in accordance with the guidance in Descriptions.