Remove the numerical error codes to be in sync with the VCDM specification #327
Conversation
* main: Changed the class name to ControlledIdentifierDocument cid->cid-1.0 Changing the references to the controller document in the vocabulary
|
The issue was discussed in a meeting on 2025-01-08
View the transcript3.1. Remove the numerical error codes to be in sync with the VCDM specification (pr cid#140)See github pull request cid#140. Brent Zundel: Remove numerical error codes to be in sync with the VCDM spec.
Brent Zundel: It does what it says. It removes the error codes while retaining the names of the error codes. Anyone want to say we don't want to do this, please say so, can take comments briefly, etc. if needed. Ivan Herman: Just remarking that there is a sister PR in the DI spec which does the same. It also makes the changes in the vocab definition file. These two PRs should go hand-in-hand. See github pull request vc-data-integrity#327. Manu Sporny: Yes, +1 -- we made a decision in the group to remove the error codes in the group and this is just Ivan making sure we follow that guidance. |
There was a problem hiding this comment.
Minor but important clean up then +1. I see VCDM's problem details isn't in sync with bitstring status list either, looks like we should just loosen VCDM and then everything will be in sync and will also match the RFC requirements (advisory only), see: https://www.rfc-editor.org/rfc/rfc9457#name-title.
| </li> | ||
| <li> | ||
| The `title` value SHOULD provide a short but specific human-readable [=string=] for | ||
| The `title` value MUST be present and SHOULD provide a short but specific human-readable [=string=] for |
There was a problem hiding this comment.
This should match what's in the other specs and not add a new MUST: https://w3c.github.io/vc-bitstring-status-list/#processing-errors
| The `title` value MUST be present and SHOULD provide a short but specific human-readable [=string=] for | |
| The `title` value SHOULD provide a short but specific human-readable [=string=] for |
There was a problem hiding this comment.
Well, actually... I have added the "MUST be present and" statement exactly to be consistent with the VCDM spec, see https://www.w3.org/TR/vc-data-model-2.0/#problem-details
I do not really care either way, we have to decide whether we align with the VCDM or we align the VCDM with this...
There was a problem hiding this comment.
Right, I think we should align the VCDM with this more flexible approach (no MUSTs) that is also closer to the RFC.
There was a problem hiding this comment.
I am neutral on this. But this should be a decision of the WG, probably to be discussed on a call.
There was a problem hiding this comment.
Hmm, looks like we have a consistency mismatch between VCDM, DI, and BSL :(. VCDM says each property MUST be present (this language). DI and BSL say SHOULD. RFC9457 says SHOULD as well.
I think we were trying to make the error messages useful by using MUST for certain properties existing (type, title, and detail). I still think that's a good idea, that is -- if you are going to raise an error, you MUST include at least those properties for the error to be immediately useful for a developer).
Let's discuss during the next WG call.
There was a problem hiding this comment.
I think we were trying to make the error messages useful by using MUST for certain properties existing (type, title, and detail).
The type property is a MUST everywhere (in all the specs already) and should stay that way. It's only the properties that are advisory from the RFC (e.g., title and detail) that I believe should be SHOULDs. I think only type is really necessary for interoperability and is what software should be using to make any branching decisions. But, these other fields are useful for developers -- and the fact that they are will drive whether or not they are included, i.e., the SHOULD provides flexibility but systems will probably include them for the best DX without us having to demand it for interop, which doesn't make sense, IMO.
| the error. | ||
| </li> | ||
| <li> | ||
| The `detail` value SHOULD provide a longer human-readable [=string=] for the error. | ||
| The `detail` value MUST be present and SHOULD provide a longer human-readable [=string=] for the error. |
There was a problem hiding this comment.
This should match what's in the other specs and not add a new MUST: https://w3c.github.io/vc-bitstring-status-list/#processing-errors
| The `detail` value MUST be present and SHOULD provide a longer human-readable [=string=] for the error. | |
| The `detail` value SHOULD provide a longer human-readable [=string=] for the error. |
There was a problem hiding this comment.
See comment here: https://github.com/w3c/vc-data-integrity/pull/327/files#r1912460821
Following up on w3c/cid#134 (comment):
Preview | Diff