Remove support for system models

[dselman]

Support for system models has complicated the codebase and makes it hard to reuse models, as they now have an implicit dependency on a system model.

On balance I think we should make a breaking change and remove the support for system models, forcing people to explicitly declare dependencies on their own models using an import with a from.

[jeromesimeon]

A few comments:

1. We need a definition for what the structure of a transaction event participant etc is. Those need to be built in in some sense
2. One of the motivations for the current structure is to be able to switch those systems model (I think two main instances are for hyperledger composer and for Cicero). There are a set of defaults for hyperledger. I believe the code could be simplified if this requirement is no longer needed (not sure if it's acceptable to remove the hyperledger system model).
3. If we revise the top of the type hierarchy, it might be nice to decide on a super type for all of classes (e.g., concept could be the super class for everything or it could be object or class)

[jeromesimeon]

Why having a top type would be useful: accordproject/ergo#420

[dselman]

1. Agreed
2. Yes, I think this is acceptable. We can preserve the hyperledger system model as a "standard" model on models.accordproject.org so that people can import it into their models and refactor if required.
3. Agreed. concept seems like a natural candidate, but that may have some API implications.

[jeromesimeon]

Small fact finding mission. I can't seem to find a clear dependency from Concerto to HL Composer:

bash-3.2$ grep -r concerto composer
Binary file composer/packages/composer-admin/test/data/businessnetwork.zip matches
composer/packages/composer-common/test/data/zip/test-npm-archive/node_modules/animaltracking-model/.npmignore:!chaincode/src/concerto
composer/packages/composer-common/test/data/zip/test-npm-archive/node_modules/animaltracking-model/models/mozart.cto:namespace com.ibm.concerto.mozart
Binary file composer/packages/composer-common/test/data/zip/test-archive.zip matches
Binary file composer/.git/objects/pack/pack-19a8cd93ba0365a189b8f632a9e5f3440428f9ae.pack matches
Binary file composer/.git/index matches

With that project being deprecated, can we assume supporting the hyper ledger composer system model is not a requirement?

[dselman]

Small fact finding mission. I can't seem to find a clear dependency from Concerto to HL Composer:

bash-3.2$ grep -r concerto composer
Binary file composer/packages/composer-admin/test/data/businessnetwork.zip matches
composer/packages/composer-common/test/data/zip/test-npm-archive/node_modules/animaltracking-model/.npmignore:!chaincode/src/concerto
composer/packages/composer-common/test/data/zip/test-npm-archive/node_modules/animaltracking-model/models/mozart.cto:namespace com.ibm.concerto.mozart
Binary file composer/packages/composer-common/test/data/zip/test-archive.zip matches
Binary file composer/.git/objects/pack/pack-19a8cd93ba0365a189b8f632a9e5f3440428f9ae.pack matches
Binary file composer/.git/index matches

With that project being deprecated, can we assume supporting the hyper ledger composer system model is not a requirement?

Yes. Composer still has an old/private copy of Concerto packaged with it - so those people will be fine.

[jeromesimeon]

Fact Finding Item Nb2. The current Accord Project system model is as follows:

namespace org.accordproject.base

/**
 * System model for Accord Project models. If you use the CiceroModelManager 
 * from the @accordproject/cicero-core npm module you do not need to import this file.
 */
abstract asset Asset {  }

abstract participant Participant {   }

abstract transaction Transaction identified by transactionId {
  o String transactionId
}

abstract event Event identified by eventId {
  o String eventId
}

Defined in: https://github.com/accordproject/models/blob/master/src/cicero/base.cto

[jeromesimeon]

Small fact finding mission. I can't seem to find a clear dependency from Concerto to HL Composer:

bash-3.2$ grep -r concerto composer
Binary file composer/packages/composer-admin/test/data/businessnetwork.zip matches
composer/packages/composer-common/test/data/zip/test-npm-archive/node_modules/animaltracking-model/.npmignore:!chaincode/src/concerto
composer/packages/composer-common/test/data/zip/test-npm-archive/node_modules/animaltracking-model/models/mozart.cto:namespace com.ibm.concerto.mozart
Binary file composer/packages/composer-common/test/data/zip/test-archive.zip matches
Binary file composer/.git/objects/pack/pack-19a8cd93ba0365a189b8f632a9e5f3440428f9ae.pack matches
Binary file composer/.git/index matches

With that project being deprecated, can we assume supporting the hyper ledger composer system model is not a requirement?

Yes. Composer still has an old/private copy of Concerto packaged with it - so those people will be fine.

Ah, I see. Thanks for clarifying!

[jeromesimeon]

The fundamental role of the systems model is to define the type names Asset Participant Transaction and Event and the build-in attributes/fields in them (e.g., in the Accord Project system model Asset has no built-in field and Transaction has a single builtin transactionId field).

With that in mind I could see a couple of options:

1. Fold the current Accord Project system model and make it built-in, so all user models assume the same definitions. A couple of decisions to make:

• What namespace should it be in. Are we happy with org.accordproject.base.
• Should we have Concept be a super type for the others, which would provide us with a well formed hierarchy with a root Concept type. This would be the equivalent of having extends Concept in those definitions.

2. Remove the system model entirely and define those names the same way we define Concept:
   This might make more sense if the implied semantic is as if we had the following systems model:

namespace org.accordproject.base

abstract asset Asset {  }
abstract participant Participant {   }
abstract transaction Transaction {   }
abstract event Event {   }

• Still similar decisions on namespace choice and whether to add an implicit extends Concept for all of those has to be made.

A drawback of 2. is that identifiers for some of those has to become part of the user models.
A benefit of 2. is that if anyone has used a system model with different assumptions from the AP ones (e.g., in which transactions do not have built-in identifier), those can more easily be ported.

@dselman @mttrbrts @sstone1 I would love your feedback on this.

[jeromesimeon]

• Agreed
• Yes, I think this is acceptable. We can preserve the hyperledger system model as a "standard" model on models.accordproject.org so that people can import it into their models and refactor if required.
• Agreed. concept seems like a natural candidate, but that may have some API implications.

One more question on this. Where can I find a definition of the hyperledger system model?

[jeromesimeon]

The fundamental role of the systems model is to define the type names Asset Participant Transaction and Event and the build-in attributes/fields in them (e.g., in the Accord Project system model Asset has no built-in field and Transaction has a single builtin transactionId field).

With that in mind I could see a couple of options:

1. Fold the current Accord Project system model and make it built-in, so all user models assume the same definitions. A couple of decisions to make:

• What namespace should it be in. Are we happy with org.accordproject.base.
• Should we have Concept be a super type for the others, which would provide us with a well formed hierarchy with a root Concept type. This would be the equivalent of having extends Concept in those definitions.

1. Remove the system model entirely and define those names the same way we define Concept:
   This might make more sense if the implied semantic is as if we had the following systems model:

namespace org.accordproject.base

abstract asset Asset {  }
abstract participant Participant {   }
abstract transaction Transaction {   }
abstract event Event {   }

• Still similar decisions on namespace choice and whether to add an implicit extends Concept for all of those has to be made.

A drawback of 2. is that identifiers for some of those has to become part of the user models.
A benefit of 2. is that if anyone has used a system model with different assumptions from the AP ones (e.g., in which transactions do not have built-in identifier), those can more easily be ported.

@dselman @mttrbrts @sstone1 I would love your feedback on this.

[For what it's worth, I think that, currently, my preferred options would be 2. + extends Concept essentially equivalent to a built-in system model as follows:

namespace org.accordproject.base

abstract asset Asset extends Concept {  }
abstract participant Participant extends Concept {   }
abstract transaction Transaction extends Concept {   }
abstract event Event extends Concept {   }

]

[jeromesimeon]

Just to make sure we are clear option 2. will break every Accord Project templates! There is certainly a very big benefit in 1. for backward compatibility in other Accord Project projects.

[dselman]

Thanks for the useful analysis @jeromesimeon. I suggest we take this up at the next WG meeting.

[jeromesimeon]

Update on this. The release-1.0 branch includes full removal of application setting systems model. This uses a base system model internally which is as follows:

namespace system
abstract asset Asset {  }
abstract transaction Transaction { }
abstract event Event { }
abstract participant Participant {  }

Some remaining open issues are listed in the corresponding PR: https://github.com/accordproject/concerto/tree/release-1.0

Those relate to the question of whether we should have a root class for the type hierarchy (#180) and revisions we should discuss for identifiers and relationships (#181)

[jeromesimeon]

@dselman Can we consider this closed based on the latest review and support in release-1.0. Remaining related questions (notably on relationships) have their own issues now.