Concerto v1.1.0

This release includes new features along with bug fixes.

🚀 Features

The main new feature is the ability to access and create models in JSON format, using a so-called metamodel written in Concerto itself. This feature is particularly useful is you need to programmatically manipulate (e.g., to generate or update) models.

• 🪞 New support for importing and exporting Concerto files into a JSON metamodel representation (#298)
• 🛰 New CLI commands cicero import to import a Concerto file into its metamodel and cicero export to create a Concerto file from a metamodel (#298)
• 📈 New support for converting Concerto models to GraphQL (#295 )

⚗️ Experimental

• Also included is experimental support for importing JSONSchema into Concerto (#294 #297) - Contribution by @mttrbrts

🐛 Bug fixes

• #302 Fix to string validators when using regular expressions with a flag

🛡️ Security fixes

• #301 Various upgrades to dependencies to address vulnerabilities

Concerto v1.0.4

This release makes some minor changes to the TypeScript API.

Concerto v1.0.3

This release make fixes to some outdated JSDoc comments and to the TypeScript interface for @accordproject/concerto-core.

Concerto v1.0.2

This release upgrades some dependencies to address security vulnerabilities.

Concerto v1.0.1

This release fixes an issue with the command line validation when using the --ergo option.

Concerto v1.0.0-alpha.10

Removes rollup bundles altogether, creating some issues in some of the downstream packages.

Concerto 1.0.0

Introduction

Concerto 1.0 delivers some fundamental improvements, whilst maintaining a high-degree (though not total!) of backwards compatibility.

Breaking Changes

• Systems models are no longer supported
• DateTime values do not preserve the timezone offset and are always converted to UTC
• Validation has been made stricter, which means some previously allowed instances will now fail validation
• The syntax and semantic of relationships has been changed

Removal of System Models

See: (#62) ✅

An advanced feature of prior versions of Concerto was the ability to add a system model to the ModelManager, which functioned as an implicit set of base types for concepts, assets, participants etc within the scope of the ModelManager. This feature complicated the APIs considerably, and it had the effect of making CTO models non-portable, in as far as they could only be loaded into a ModelManager that used the same set of system models.

System models have therefore been removed from Concerto v1 — any base types should now be imported and referenced explicitly into model files.

Strict Validation

See: (#158 #157 ) ✅

Prior to Concerto v1 validation suffered from some side-effects of JavaScript type-coercion. For example, "NaN" would be a valid value for a Double field. These edge cases have now been tightened up, so some instances that were valid prior to v1 may now fail validation.

Identifiers and Relationships

See: (#181) ✅

Prior to v1 a relationship could only be declared to an asset, participant, transaction or event (as these must be identified by). In v1 two new capabilities have been added:

1. Concepts can now be declared to be identified by an identifying field, allowing them to be used with relationships
2. Any type can be declared as identified — to automatically create a system $identifier field.

The model below is valid with Concerto v1.

namespace org.accordproject

concept Address {
   o String country
}

concept Product identified by sku {
   o String sku
}

concept Order identified {
   o Double ammount
   o Address address
   --> Product product
}

Root of Type Hierarchy

See: (#180) ✅

All declared types now have concerto.Concept as their super type, and the concerto namespace is reserved. Note that the super type for concerto.Concept is null.

Functional API (experimental)

See: (#188) ✅

A new streamlined Concerto API has been added, to replace some of the existing runtime APIs. Existing runtime APIs have been preserved, but will be progressively removed.

The Concerto API is much more functional in nature, and allows plain-old-JavaScript objects to be validated using a ModelManager — removing the need to use the Factory API to create JS objects prior to validation, or to use the Serializer to convert them back to plain-old-JavaScript objects. This should reduce the learning-curve for the library and improve performance.

const { ModelManager, Concerto } = require('@accordproject/concerto-core');
const modelManager = new ModelManager();

modelManager.addModelFile( `namespace org.acme.address
concept PostalAddress {
  o String streetAddress optional
  o String postalCode optional
  o String postOfficeBoxNumber optional
  o String addressRegion optional
  o String addressLocality optional
  o String addressCountry optional
}`, 'model.cto');

const postalAddress = {
   $class : 'org.acme.address.PostalAddress',
   streetAddress : '1 Maine Street'
};

const concerto = new Concerto(modelManager);
concerto.validate(postalAddress);

Concerto v1.0.0-alpha.9

This release fixes and issue with the new rollup build process.

Concerto v1.0.0-alpha.8

This alpha release:

1. Fixes issues with Concerto.instanceOf (#264 )
2. Adds a new --utfOffset option to the command line
3. Adds utcOffset configuration to the model manager and serialized
4. Switches bundling from webpack to rollup

Concerto v1.0.0-alpha.7

This alpha release consolidates validation targeting the ergo ES6 runtime. It also includes:

• Fixes to the ModelFile API: removing unused system file options
• A new and more efficient loader for external models (contribution by @mttrbrts )
• Dependency upgrades