Skip to content

Update Agreement Concept with additional attributes - #7

Merged
dselman merged 2 commits into
accordproject:mainfrom
beNEXT-io:main
Jan 25, 2023
Merged

Update Agreement Concept with additional attributes#7
dselman merged 2 commits into
accordproject:mainfrom
beNEXT-io:main

Conversation

@martinhalford

Copy link
Copy Markdown
Member

Signed-off-by: Martin Halford martin@benext.io

Add properties/attributes to Agreement Concept in order to better support instantiation of agreements.

This includes:

  • Parties
  • State
  • History
  • Signatures
  • Attachments/References
  • Metadata

This PR is intended to be a work-in-progress / draft proposal / starting-point upon which to iterate.

Signed-off-by: Martin Halford <martin@mantradao.com>
Comment thread model/protocol.cto Outdated

import concerto.metamodel@0.4.0.{Property,ConceptDeclaration,Model} from https://models.accordproject.org/concerto/metamodel@0.4.0.cto
import org.accordproject.commonmark@0.5.0.Document from https://models.accordproject.org/markdown/commonmark@0.5.0.cto
import org.accordproject.party.* from https://models.accordproject.org/accordproject/party.cto

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should use an explicit (no '*') versioned import.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. Setting to import org.accordproject.party@0.2.0.*

Comment thread model/protocol.cto
o AgreementParty[] agreementParties // Parties to the agreement
o Signature[] signatures // Signatures of the parties to the agreement
o AgreementStatusType agreementStatus // Current status of agreement
o History[] history // History of document state and details.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

optional?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As agreementParties, signatures, and history are all arrays, and can be empty, then I thought it would be safer & simpler to make them mandatory. All agreement instances will, ultimately, have agreementParties, signatures, and some history- therefore, not wasted space.

As for agreementStatus, I was thinking that any agreement instance must have a status - either Draft, Signing, Completed or Superseded - so, personally, think this should be mandatory. If we come across a use case that is not handled by these 4 status types then we can add it (e.g None could be an enum).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on this logic, I've removed optional from other arrays in the bits I added. Must admit, optional fields have caused me pain in the past - so tend to use them only when I have to. :-)

Comment thread model/protocol.cto Outdated
concept Signature {
o AgreementParty signatory // The Agreement Party signing the Agreement
o DateTime signedAt optional // When the signing occurred
o String[] metaData optional // Geolocation data, IP address, etc.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

differs in case "metaData" from rest.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have standardised on camel case.

Comment thread model/protocol.cto Outdated
o DateTime dateTime
o AgreementStatusType agreementStatus // Status at time of change
o JSON data // Data at time of change
o String[] metadata optional // Additional data that may be relevant to the agreement at time of change

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

3x instances of metadata - perhaps this should be a concept?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could do but it felt like overkill for a single data field - it's just a data bucket at the moment.

If this needs to become more complicated, say, with multiple named fields and data types then we should def. make it a concept.

@dselman dselman left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

…se typo.

Signed-off-by: Martin Halford <martin@mantradao.com>
@dselman
dselman merged commit 3235343 into accordproject:main Jan 25, 2023
JayDS22 added a commit to JayDS22/apap that referenced this pull request Jul 18, 2026
…6 sync decisions

Applies the factual corrections Steven flagged in his approval review on this
PR and folds in the Jul 16 sync outcomes so the doc reflects current reality.

Steven's factual fixes:

- Status header: "Six PRs merged" corrected to "Eight PRs" and the full
  list updated to include accordproject#208 (which merged Jul 13 rather than sitting as
  "awaiting maintainer merge")
- "Five parallel lanes" corrected to "Six parallel lanes" now that
  Workstream 6 (Headroom compression eval) is on the doc
- "slice 2" references to accordproject#200 renamed to "slice 3" throughout to match
  the PR title; accordproject#197 explicitly referenced as the closed slice-2 draft it
  replaces
- pino refactor line: "~28 console.log sites" corrected to "17
  console.log + 11 console.error sites" per Steven's exact count

Memorialization note added to the workstream table intro explaining that
Workstream 6 plus the Comms deliverables and Future work sections were
added mid-project with mentor input (Niall Jul 14 Discord on the ACE-Router
thread, Steven Jul 16 review asking that the scope expansion be
memorialized).

Jul 16 sync outcomes:

- Status header now reflects W7 day 5 with the PR accordproject#7 subscriptions/listen
  slice shipped on the POC and issue accordproject#8 tracking the US-C4 follow-up
- Explicit note that this PR (accordproject#198) stays open as the rolling roadmap doc
  through end of GSoC per Niall's Jul 16 call

Signed-off-by: Jay Guwalani <guwalanijj@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants