Update context to include latest BitstringStatusList changes.

[msporny]

This PR updates the base context to include the latest BitstringStatusList context updates made in PR w3c/vc-bitstring-status-list#109.

[dlongley]

Approving this, but we should expect some additional fixes to the BitStringStatusList-related entries here as we work through issues there.

[selfissued]

It would seem more modular to have StatusList have its own context, distinct from the VCDM context.

[msporny]

@selfissued wrote:

It would seem more modular to have StatusList have its own context, distinct from the VCDM context.

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).

[iherman]

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)

[iherman]

The issue was discussed in a meeting on 2024-01-03

• no resolutions were taken

View the transcript

1.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.
… don't have to pull in another context. doesn't cost us much. does this impact your position?

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.
… if we don't put this in as well then it is confusing. don't follow what we had consensus on in the group.
… is this a formal objection? on which technical grounds?

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.
… once status list and VCDM are in CR then the values are stable. have mitigated the concerns. feels like we're re-opening an old debate without new information being brought to light. would need to hear from others in the group about this.

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.

Phillip Long: The current PR #1406 seems like a reasonable compromise between those that want separate context files for everything & those that want to have fewer for just the specs in working group.

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.

[msporny]

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.