Comments (14)
Thanks for the useful analysis @jeromesimeon. I suggest we take this up at the next WG meeting.
from concerto.
A few comments:
- We need a definition for what the structure of a
transaction
event
participant
etc is. Those need to be built in in some sense - 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).
- 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 beobject
orclass
)
from concerto.
Why having a top type would be useful: accordproject/ergo#420
from concerto.
- 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.
from concerto.
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?
from concerto.
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.
from concerto.
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
from concerto.
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!
from concerto.
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:
- 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 rootConcept
type. This would be the equivalent of havingextends Concept
in those definitions.
- 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.
from concerto.
- 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?
from concerto.
The fundamental role of the systems model is to define the type names
Asset
Participant
Transaction
andEvent
and the build-in attributes/fields in them (e.g., in the Accord Project system modelAsset
has no built-in field andTransaction
has a single builtintransactionId
field).With that in mind I could see a couple of options:
- 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 rootConcept
type. This would be the equivalent of havingextends Concept
in those definitions.
- 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 whichtransactions
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 { }
]
from concerto.
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.
from concerto.
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)
from concerto.
@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.
from concerto.
Related Issues (20)
- Provide an API to extend the default rules of the analyser
- Inconsistent ast types in introspect HOT 2
- Issue trying to validate declarations without properties
- Support Decorator Command Set validation independent of applying decorators
- Support max length for array and map
- "Install the Command Line Tool" link is broken in readme
- Vocabulary support for Map Types in Concerto HOT 3
- JSON Schema output is not working for Scalar Arrays
- Concerto CLI parser allows multiple application of the same Decorator, but not ModelManager HOT 1
- Should not be able to create a concept whose super type is itself
- Decorator Command with properties without a type adds decorator to declaration
- feat: Extract the vocabulary set and decorator command set from a model manager
- Remove Functional API
- VocabularyManager: support configurable fallback locales
- Migrate to ESM from CommonJS Modules HOT 1
- Map does not support polymorphic values HOT 1
- While validating a `ConceptDeclaration` with no properties, the validation fails ungracefully if the `properties` field of the AST is `null` HOT 2
- Errors when creating validators in concerto introspect only return a string in a error message , which makes programatic handling the errors dificult
- Vocabulary auto generated for $identifier HOT 5
- toAst and fromAst are not identity operation HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from concerto.