2.0.119

• Two additional ISDA Create NY Law documents were added to the ingestion/isda_create menu
• Fix the display of portal apps based on the user’s role.

2.0.116

Further Documentation Update

Following the documentation overhaul in previous release 2.0.115, some further upgrade has been implemented, notably:

1. Expanded explanation about the key implementation in the Rosetta DSL documentation. JSON snippet has been provided to illustrate implementation of the ‘internal’ and ‘external’ cross-referencing mechanism, whilst making it clear that this is part of the default Rosetta implementation but not part of the model itself (i.e. implementors can choose to do it differently and may choose to discard the ‘external’ references for instance).

2. Refactored the CDM ‘Product Model’ section to enhance explanation about the model composability.

Review directions

Go to the Documentation / ISDA CDM tile in the CDM Portal, also directly accessible here:
https://portal.cdm.rosetta-technology.io/modeldoc/index.html

2.0.115

Updated Documentation

CDM Documentation as available on the portal has been entirely revisited. Notable changes and additions are:

1. Clean separation of the documentation for the “Rosetta DSL”, which is now attached to the Rosetta DSL repo (https://github.com/REGnosys/rosetta-dsl). This follows the recent open-sourcing of the Rosetta DSL, which requires an associated (and stand-alone) documentation.
2. Update to reflect recent work on Function Specification, both in terms of the syntax in the Rosetta DSL documentation, and usage as part of the CDM documentation, in particular for event specifications. Function specifications have been folded as part of a broader Function category in the CDM documentation, which also comprises the calculation components, so that the two can be compared and contrasted.
3. Updated components diagram at the top of the documentation, aligned onto the structure of the various GitHub repos. The naming of model artefacts presented as CDM components in the diagram has been aligned onto the CDM artefacts presented in the documentation.
4. Significantly improved readability through a combination of form and content work. Documentation has been re-designed to flow more easily by re-thinking some of the ordering and indexing and a better use of bullet points. A number of explanations have been altered or plainly re-written and some examples have been adjusted.
5. Updated examples following recent alterations in the model, in particular regarding the calculation syntax.
6. Small update to reflect recent work on Equity Swap, with examples.
7. Notes provided where some re-assessment or refactoring or current status-quo should be considered.

Note: The Rosetta DSL documentation is referred by a link in the CDM documentation. This links takes the user to a GitHub page where documentation is displayed in a different theme than the one on the portal. More work will be required so that both the CDM and Rosetta DSL documentations can be merged and displayed under the same page and theme in the portal.

Review directions

Go to the Documentation / ISDA CDM tile in the CDM Portal, also directly accessible here:
https://portal.cdm.rosetta-technology.io/modeldoc/index.html

2.0.113

Functions UI

To better demonstrate Function Specifications or specs a new UI was built to demonstrate an example sequence of events that includes making use of specs.

The Functions UI starts by loading data into a “database”, which is done by converting a set of XML or FpML documents into CDM objects. Objects in that “database” are then used to invoke spec implementations which in turn produces further CDM objects as output. Specs implementations can be invoked one after another to form a chain of invocations.

The results of the initial data loading as well as subsequent spec invocations can be graphically visualised in a diagram that shows (in blue arcs) the Event Lineage and (in grey arrows) the essence of what each CDM object contains within it.

This UI replaces the Lineage UI.

Review directions

In the Portal, see the Functions UI, in the drop-down select the equity-swap example. In the section labelled Sequence Data are the external FpML Equity Swaps Confirmation message, its corresponding CDM Contract object (in JSON format) and all the associated CDM objects that were extracted from that Contract.

Below that, in the Invoke Function section, see the spec inputs and output. In parenthesis are the Global Keys of the objects being used in the function invocation. Those Global Keys will correspond to those found in the tab headings of the Sequence Data section.

Invoking a function will display the result of that invocation, which will be a CDM object in JSON format. The Lineage visualisation also updates as a result, reflecting creation of new CDM objects.

Spec Implementation

Each spec requires an implementation and for the purposes of producing the equity-swap example in the Functions UI, a number of example implementations were created to demonstrate how a CDM user could choose to proceed. It highlights what logic needs to be implemented versus what is provided by the spec itself.

Review Directions

In the CDM Distribution pack, unzip the cdm-sources Java Archive and see folder src/main/java/org/isda/cdm/functions/example for examples of Spec Implementations. NewContractEvent.java and NewExecutionFromProduct.java are good examples to start with. Note: take care to inspect RosettaFunctionExamples.java on how dependency injection is managed.

2.0.111

Rosetta Grammar and Code Generator support for Function Specifications.

Continuing from previous work that added support for Function Specifications or specs for short, the Rosetta Grammar was upgraded to support all the expressions required to define the specs released from version 2.0.88 and onwards.

Specifically, grammatical rules for exists, is absent, contains, if statements and references to other specs were added, making re-use of infrastructure that was in place for data rules.

Java Code Generation support was added for specs. For each spec a corresponding abstract Java class will be generated which defines the inputs, outputs, pre-conditions and post-conditions of a function. It also asks implementors to provide a concrete implementation of an “enrichment” function that should deal aspects of CDM object construction that are not captured by the spec itself.

Logic inside the generated Java classes reside mainly in the pre and post conditions, where code generation now supports in Java the full set of operators available in the grammar.

Review directions

In the Textual Browser, where sections of specs were disabled with TODO:s marking instances where upgrades to grammar and code generation were required.

In the CDM Distribution pack, unzip the cdm-sources Java Archive and see folder /src/generated/java/org/isda/cdm/functions for examples of generated Java code. NewContractEvent.java and QuantityChange.java are good examples of where to start looking.

2.0.106

Rosetta DSL and code generators are now public

We have made the following github repositories open source under the Apache 2.0 licence and publicly available:

https://github.com/REGnosys/rosetta-code-generators

https://github.com/REGnosys/rosetta-dsl

2.0.105

Calculation Bug-Fix

Fix for the interest rate calculation page in the CDM Portal, which had recently been broken as a side-effect of other changes to the model.

Review directions

Visit the “Calculation” page in the CDM Portal and try some calculations.

2.0.104

1. Underlier Refactoring

Usage of the Underlier is being refactored to be consistent across all pay-out types that make reference to it, namely:

• EquityPayout (where Underlier was being uniquely used before)
• OptionPayout (which was using Product before)
• ForwardPayout (which directly specified the types of underlying products which could be used before)

As part of this refactoring, the settlementTerms attribute has also been rationalised within the ForwardPayout class, which now works in the same way as the OptionPayout class. The previous settlementDate attribute has been deprecated and moved to the broader settlementTerms one.

Note: a valueDate attribute of type date needed to be added within settlementTerms in order to make this work with ForeignExchange pay-outs because date is specified in hard, not adjustable. This should be fixed and merged with the existing settlementDate attribute, once the usage of various types of dates (absolute, adjustable or relative) is being refactored.

Review directions

See OptionPayout and ForwardPayout, and the “Ingestion” page on the CDM Portal for option and fx products.

2. DAML Download Disabled

Compiler has changed on DAML side, such that DAML code generated from CDM no longer builds. This will have to be looked as part of a subsequent release.