-
Notifications
You must be signed in to change notification settings - Fork 106
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
Update context to include latest BitstringStatusList changes. #1406
Conversation
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.
Approving this, but we should expect some additional fixes to the BitStringStatusList
-related entries here as we work through issues there.
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.
It would seem more modular to have StatusList have its own context, distinct from the VCDM context.
@selfissued wrote:
That will (also) exist if PR w3c/vc-bitstring-status-list#109 is merged. That said the WG made a decision many months ago to put terms that are broadly useful, like the ability to express status lists, into the base VC context. That is what this PR does (makes developers lives easier, so they don't have to track down an extra context to use the status list mechanism that this WG is producing). |
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.
Approve, but with the note that the vocabulary URL for the bitstring status terms may change, so it would be wise to wait with the merge until that is settled (and, if necessary, make changes on the final context file)
The issue was discussed in a meeting on 2024-01-03
View the transcript1.6. Update context to include latest BitstringStatusList changes. (pr vc-data-model#1406)See github pull request vc-data-model#1406. Brent Zundel: 1406: more recent. update context to include latest BitstringStatusList changes. open to discussion. Manu Sporny: mostly a question to selfissued. I think Mike is opposed to the PR. tried to respond to the concerns. to paraphrase - feel it would be more modular to have status list in its own context. we decided a while ago to not do this to make devs lives easier. Michael Jones: no not really. there were objections to that decisions (I was one). still object. do not have criteria for what does/nt go in the base context. always taken a position that the base context should be what's in the base data model. context for status list, etc. otherwise it becomes a popularity contest, where we are now. Manu Sporny: objective criteria: things this working group are working on. not a popularity context. it's the set of specs this group is standardizing. includes vc-jose-cose, status list, other spec that we feel are applicable. that's where we got to consensus. don't agree with the characterization. Michael Jones: the problem is...by losing the modularity the context for the data model is dependent on every other spec finishing at the same time which isn't realistic. we have dependencies on stuff with varying degrees of completeness. better off to have a context for each spec. Manu Sporny: would be good to hear from others. what we're trying to do is optimize. had complaints from implementers earlier on. we have statements to mitigate your concern Mike. once in CR things are locked pretty well and stable. Brent Zundel: chair hat fully on. I remember this debate. brought an issue myself. we had this conversation. the result was the context file is a collection of whatever folks feel is convenient for implementers. that's why it includes vc-jose-cose, etc. that's my understanding. Dmitri Zagidulin: agree with you Mike that we should have clearly defined parameters of what goes into the context (shouldn't be popularity). we do at the moment have these parameters: just the specs going to CR in this working group. no problem with this.
David Chadwick: I agree with Dmitri. if we have a spec lagging behind we have a problem. never goes to CR = no problem. goes to CR much later = problem, since a definition can change. boils down to how fast are they all progressing. are they at the same speed? Brent Zundel: my recollection that we have language in the spec that addresses this (values can change before CR). please correct me if wrong. David Chadwick: if one goes to CR much later then there would be a problem. Brent Zundel: agree. Manu Sporny: to address that problem the WG can choose to remove those values. if we are in that position we can have a discussion to keep the values or not. Brent Zundel: for those who don't like the 'kitchen sink' approach. that's where we're at now. would be a change to not continue adding to the sink. |
beaddf3
to
7fb1e06
Compare
7fb1e06
to
4d0b289
Compare
Normative, multiple reviews, changes requested and made, one objection by @selfissued that the WG discussed and determined not to revisit due to a prior consensus decision, merging. |
This PR updates the base context to include the latest BitstringStatusList context updates made in PR w3c/vc-bitstring-status-list#109.