Closed kaiqu closed 7 years ago
In the model, suggested statuses are Nominated, Accepted and Rejected. But the get-response example has status = "live"?
I see the XSD has "nomination", "live", "rejected", "recognized" and "cancelled". The last two are new and presumably necessary (I will update the model). The first three correspond to Nominated, Accepted and Rejected in the model. I think standardizing on "verb in past tense" is more consistent, but I don't have strong opinions about it. However, the model and XSD should be consistent with each other, so let me know what you decide, @wrygiel .
The difference comes from the fact, that the model dealt with "the status of the nomination", and I have tried to expand this to a bit broader "status of the mobility".
However, I'm not sure if my initial proposal is the best approach (we could have trouble when it comes to adding more statuses in the future). Other solutions are possible. For example this could work too:
<nomination-status>accepted</nomination-status>
<recognized>true</recognized>
<cancelled>false</cancelled>
What do you think? Which solution seems better to you?
@erasmus-without-paper/all-members
However, I'm not sure if my initial proposal is the best approach (we could have trouble when it comes to adding more statuses in the future). Other solutions are possible. For example this could work too:
"nomination-status" = accepted "recognized" = true "cancelled" = false
What do you think? Which solution seems better to you?
(I have replaced the field brackets with double quotes to keep quoted text readable)
There are two concerns here:
The above code examples would therefore make sense if:
What would be the possible combinations of these three fields?
What would be the possible combinations of these three fields?
I believe that only accepted nominations can be recognized (1 combination here). But also not-yet-accepted nominations can be cancelled (2 combinations).
I believe that only accepted nominations can be recognized (1 combination here).
But they don't have to be, so there are two combinations.
But also not-yet-accepted nominations can be cancelled (2 combinations).
So we have the following states:
Which translates to the following combinations of the three suggested fields:
nomination-status | cancelled | recognized |
---|---|---|
nominated | false | N/A |
nominated | true | N/A |
rejected | N/A | N/A |
accepted | N/A | false |
accepted | N/A | true |
This leaves most combinations unused, and I would rather suggest a single Status field with these values and transitions:
You're right, I didn't use the definition of combination correctly :) What I - kind of - meant was 2^1=2 (instead of 1) and 2^2=4 (instead of 2).
Anyway, I believe "accepted => cancelled" is also a perfectly valid transition. Also "cancelled => nominated" might be possible, or even "cancelled => accepted".
Do you think that "accepted mobility" is better than "live mobility"?
Anyway, I believe "accepted => cancelled" is also a perfectly valid transition. Also "cancelled => nominated" might be possible, or even "cancelled => accepted".
Ok. Then there are so many valid transitions that it doesn't seem to be much point in defining validity.
Do you think that "accepted mobility" is better than "live mobility"?
On second thought, I guess "live" is somewhat better. Which leaves us with the following statuses:
Do you think that "accepted mobility" is better than "live mobility"?
BTW - I have used "nomination" instead of "nominated" for similar reasons (because "nomination-mobility" sounded a just slightly better than "nominated mobility").
I'm still not certain whether these 5 statuses will be enough, but I think we still have a couple of months before we upgrade this specs to "stable".
In the model, suggested statuses are Nominated, Accepted and Rejected. But the get-response example has status = "live"?