-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add message schemas and shapes #3
Conversation
}, | ||
"ids:rejectionReason": { | ||
"type": "string", | ||
"enum": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should define this (the enum)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is already part of the current info model. We can take a look if there is a different vocabulary out there. Not defining its values is however not an option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this not an option? If you leave it open as String
, one could add information as needed. And its processing COULD be defined in the protocol binding - if you want to enforce a unified processing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
from our call:
- enum is not the right keyword
- syntactic or message-related errors must result in protocol-native error codes
- we can recommend certain "well-known" values and a pattern (e.g. "COUNTER_OFFER_NOT_ACCEPTABLE")
- Idea: move the rejectionReason to the NegotiationTerminationMessage field terminationReason?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will update the files accordingly.
@jimmarino @juliapampus I am done with the first iteration in the message schemas. |
|
||
**Response**: [ContractNegotiation](./message/contract.negotiation.json) containing the negotiation id or ERROR. | ||
**Response**: [ContractNegotiationMessage](./message/contract-negotiation-message.json) containing the negotiation id or ERROR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above. The response should not be a message but the object, in this case ids:ContractNegotiation
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
dct:description : MultilanguageProperty | ||
} | ||
|
||
enum ids:RejectionReason { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We didn't want to predefine rejection reasons, right? Because the error code should be protocol binding specific. So just ids:errorCode
or ids:code
of type String
.
@@ -1,7 +1,7 @@ | |||
{ | |||
"@context": "https://w3id.org/idsa/v5/context.json", | |||
"@id": "urn:uuid:a343fcbf-99fc-4ce8-8e9b-148c97605aab", | |||
"@type": "ids:ContractNegotiation", | |||
"@type": "ids:ContractNegotiationMessage", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As above, this thing here defines the ids:ContractNegotiation
that should not be wrapped into a ContractNegotiationMessage
as response.
@type : "ids:ContractNegotiationTerminationMessage" | ||
ids:processId : String | ||
ids:code : ids:TerminationCode | ||
ids:reason : ids:Reason |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Referring to my comment above, we should keep ids:code
and not replace it by ids:rejectionReason
. So, IMO it is okay to have this reason value as an add-on. Nevertheless, I don't think we should put effort in pre-defining ids rejection reasons.
I have finished the main work on the schemas. A colleague of mine will do a quality check and also provide schemas for DCAT Catalogs and ODRL later.
|
I think some changes need a dedicated approval/discussion @jimmarino
I have some local cleaned up history, however, this will require more effort than just cherry-picking some commits/changes. How to proceed? |
ecc5503
to
6a4be50
Compare
6a4be50
to
b2c5efe
Compare
b2c5efe
to
6950efe
Compare
Relates #35 |
6950efe
to
281f5fb
Compare
@juliapampus your changes are fine with me, thanks for the effort! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Due to the length, it's a bit hard to go through specifics. I'm fine in principle as long as the enums are removed/
Closes #17
Closes #18
Closes #19