Remove the at risk issue marker for `Evidence` about vc-data-model

[iherman]

The issue was discussed in a meeting on 2023-10-25

• no resolutions were taken

View the transcript

2.2. Remove the at risk issue marker for Evidence (issue vc-data-model#1303)

See github issue vc-data-model#1303.

Brent Zundel: noting this is labeled as 'Before CR', but we don't have anyone assigned.
… 'Remove at-risk marker for Evidence'.
… where do we go with this?

Orie Steele: the linked issue is about termsOfUse, which is one of the expiring pending close ones?

Manu Sporny: it'll be merged on its current path.

Orie Steele: to recap, there is an open PR, looks like it'll get merged. so once we see something about Evidence, we'll remove at-risk marker.

Manu Sporny: we should ask the EBSI folks to see if they volunteer?

Brent Zundel: sounds like Dmitri is also volunteering, so, with permission, I'll assign it to you.
… next issue, 1292.

[msporny]

In an attempt to reduce the number of before-CR issues we have to process, I'm going to change this to post-CR since CR is when we do testing. Removing the at risk issue marker before CR or during CR doesn't seem like it will impact the timeline at all. Either we will have tests and remove the issue marker during CR, or we won't and people will lobby for the feature to be removed during CR.

[iherman]

The issue was discussed in a meeting on 2024-02-14

• no resolutions were taken

View the transcript

2.1. Remove the at risk issue marker for Evidence (issue vc-data-model#1303)

See github issue vc-data-model#1303.

Michael Jones: looking at 1303 first Remove the at risk issue marker for Evidence.

Manu Sporny: See section in the spec.

Manu Sporny: question for the group: Jefferey Yaskin asked for a mini-registry and to be done with this. we could do that. w.r.t tests what did we say we would do? I have two recollections.
… have to demonstrate there is a spec using the property. there are multiple impls. 1EdTech have an evidence property. thought the tests we were writing were just testing the 'type' for evidence. need to ask what are we testing for these extension points.
… normative guidance we give is : it can't be empty, have to specify it's type, id should be a URL, ... 1EdTech has multiple impls. at what point do we remove the at risk marker? when we create tests?
… is that the bar we're trying to hit?

Ivan Herman: from a practical point of view, the only obligation we have is to remove these markers and feature itself when we go to PR. at this point there is no rush. at some point we'll have to look at the whole test suite report and then risk markers.
… issue was raised before CR. why bother at this point? went to CR with marker in.

Brent Zundel: less a post-CR and then a pre-PR?

Ivan Herman: yes.

Manu Sporny: #1295 (review).

Manu Sporny: agree, but still need clarity. Orie said the example needs to be updated and covered in tests. what does 'covered' mean? ... having input/output that looks like the example. then we can remove the at risk flag. concretely we update the example to use the IMS Global evidence property.
… there will be a test for that in the core data model. to make sure there's a type and to make sure nobody throws an error (or at least 2 don't.) and then at if at the end of CR two impls are doing this, we remove the issue marker.

Gabe Cohen: +1 to that proposal.

Manu Sporny: does anyone disagree with that proposal?

Manu Sporny: +1 for it being for how we evaluate /all/ properties.

Manu Sporny: (all "at risk" properties).

Ivan Herman: fine with that. need to be clear this is not for the evidence property only. what's being described is 'how do we accept that a given property/term stays in the spec as a normative thing' need a general approach to do that.

Brent Zundel: labeled as before-PR. manu has outlined a clear course of action. no one assigned yet.

Ivan Herman: Manu has outlined ... but needs to be documented somewhere.
… will there be some document that says this is the way we remove the markers?

Brent Zundel: do you have a proposal?

Ivan Herman: at the end of the CR process we need a report. to say whether we are fine or not. criteria may differ, this is not in the same category as other issues. my proposal is to have a document and record this in it.

Manu Sporny: I have raised an issue to track this (#1437), will add details. to remove at risk issue markers & properties. will be a before-PR thing. will document the process and track at risk properties.

See github issue vc-data-model#1437.

Brent Zundel: can anyone take the issue?

Manu Sporny: yes, I will.

[iherman]

The issue was discussed in a meeting on 2024-02-28

• no resolutions were taken

View the transcript

3.9. Remove the at risk issue marker for Evidence (issue vc-data-model#1303)

See github issue vc-data-model#1303.

Brent Zundel: Remove the at-risk marker for evidence.
… This is on our list of before-PR actions to take, Manu do you need anything?

Manu Sporny: I added another issue to track this. Can we close this one?
… We're tracking it elsewhere.

Brent Zundel: I believe the other one covers this.
… Proposal is to close this one because an umbrella issue is tracking this one.

Manu Sporny: +1 to close because it's being tracked in 1437.

Brent Zundel: Anyone opposed?

David Chadwick: I'm not opposed to closing at all. We ought to make a note somewhere that if any of these have had the at-risk marker removed then they fail the conformance testing, then they need a W3C-CCG spec written for them?

Manu Sporny: No, they need a spec somewhere for them. Where we see two different implementations being able to handle the markup for it.
… I think the resolution a couple of weeks ago -- and we did minute it...
… Was that spec has to exist, multiple implementations must exist, but the only thing this WG needs is an example that uses the markup from that other spec.
… And request that the issuers issue a VC with that stuff -- and if they can do that, (multiple issuers), e.g., multiple issuers with evidence do it, then we're good, the feature stays in the spec.

David Chadwick: If they don't pass that threshold, my understanding is that a CCG spec should exist.

Manu Sporny: It's any spec.

David Chadwick: We may need to change the wording, the description, I'll go look again.

Ivan Herman: I may ask the same question as David just differently.
… These properties in the vocabulary, they may refer to a CCG document for their normative description; as long as they are an extension point and not really part of the vocab and that's ok. If we remove that marker and they become bona fide properties...
… Then we have to have normative text in the VC spec to refer to.
… Just making sure this will happen.

Manu Sporny: My understanding is that the extension specification, the only thing that is required for the extension point, is that we have a test in the VCDM 2.0 test suite. So looking at "evidence", we have a test in the VCDM 2.0 test suite, it has an evidence field that is populated using an external spec.
… It has another context for that evidence extension.
… And there will be a type that's used in the evidence field that uses that extension property.
… We don't have to do anything else. I think that's the agreement that the group came to.
… We have to demonstrate a spec is out there, multiple people using it, we test that with a test here in the VC 2.0 test suite.

Ivan Herman: I am looking at the vocab spec. The evidence refers back to the data model, so we're fine there. The same with refreshService, but renderMethod refers to a CCG document.
… That's what I'm worried about.
… All the others refer back to the VCDM spec as the source for the property specification, I'm worried just about renderMethod.

Manu Sporny: I don't think renderMethod and confidenceMethod will make it into the main spec, but they will be reserved.

Ivan Herman: Ok, just wanted to make sure.

[brentzundel]

Covered by another issue, no objections raised since being marked pending close, closing