VCWG Render Method

VC Render Method Call

Dmitri_Zagidulin: Welcome everyone.

Dmitri_Zagidulin: All right, welcome everyone to the VC render method task force of the verifiable credential working group call that is now weekly for Those you in the US, I hope you had a good Labor Day. now it's time for more standards labor. As always, we're under W3C code of conduct and IP restriction agreements. You need to be member of the group, So, today we have a fairly open agenda.

Pending PRs and Issues

Dmitri_Zagidulin: I would like to go through a couple of the pending PRs and some of the issues that have recently been addressed just to make sure that we close them. I want to talk a bit about the security and privacy self questionnaire that Mana opened. and of course feel free to add other items to the agenda. Going to the request First, we have the poll request number 74 by our very own Benjamin here in link in chat.

Renaming "Card" to "Highlights"

Dmitri_Zagidulin: We had a couple of wording suggestions that Benjamin just addressed. we need to resolve conflicts. But aside from that, does anybody have any other comments or objections from for the spoiler request which just renames card to highlights and also tweaks some of the language renaming card to Go ahead.

Discussion on "Highlights" Terminology

Ivan_Herman: Yeah, I am a little bit lost in all the discussions we had, but I don't think that we had a full agreement on using highlight as a term.

Ivan_Herman: I don't want to spend too much time on bike shedding, but there was a disc discussion somewhere, frankly, I don't remember exactly where.

Dmitri_Zagidulin: Yes. …

Dmitri_Zagidulin: there was a discussion on the August 25th call where you said that there was no agreement about highlights as the possible Other suggestions such as summary and priority fields were brought up. So on this call, I wanted to sort of refresh

Dmitri_Zagidulin: people's memory since it's been a couple of weeks on hey this is still pending. We know it's not going to be cards highlights of suggested but it doesn't have fully consensus. So we have other two working suggestions summary and priority. go ahead Nate and then Dave.

Nate_Otto: I was just hoping to hear maybe from Benjamin and Dave, if your summary of the changes, the highlights of the changes to this was complete or if there was any significant, change to what actual data was displayed. I'm scanning through the PR now.

Dmitri_Zagidulin: D. Go ahead.

Dave Longley: Yeah, I'd have to go back and doublech check line by line. okay.

Benjamin_Young: I can speak to that real quick,…

Benjamin_Young: Dave, and then I did not intend to change any functionality.

Dave Longley: Got it.

Benjamin_Young: I do think it does include the removal of valid from and valid to however, but everything else should have just been renamed.

Dmitri_Zagidulin: Yeah. confirmed Dave

Dave Longley: Yeah, that was my memory as because we also had some other proposals for making it a little clearer where things are JSON pointers and I think that would be a subsequent change. I still don't know if highlights is the name we ultimately want to go with, but I do think it's an improvement on card because it's a little more abstract and we didn't want to signal to people that they had to literally build a very specific UI component if they use this. And so, in that respect, I think it is definitely heading in the right direction. Maybe it will end up being what makes the most sense.

Dave Longley: My main problem with it is I do expect people to want to use this not just for highlights but for prioritizing everything if they want to. and that I don't think there's a problem with people electing to do that. People being issuers they can put everything in they can prioritize everything and make everything a highlight. But I think if the name says highlight that they might think they can't do that. and I also understand that some of us would prefer to signal that they should only highlight some things, but I also don't know if that's really the right thing to do. so those are my main things about thoughts on the name highlight.

Dave Longley: I do think it's better than card and for that reason we should probably rename it so it's at least heading in the right

Dmitri_Zagidulin: Thanks, Dave.

Dmitri_Zagidulin: I wanted to hop on the queue to say to advocate for summary instead of priority for a couple of reasons. The most common use case for this field is to display it on a list or to summarize to do a subset somehow which does not at all require prioritizing the Asking issuers and template designers to put fields in priority order when it's not may be too confusing.

Dmitri_Zagidulin: We can add a priority field just in case they want to, but I don't think we should put that front and center. Manu

Manu_Sporny: Plus one to summary. so, given only two choices between card and highlight, let's do highlights, So, that's clearly better, but I feel we're just going to change the name again in the future. So, can we maybe spend the time to bite shed it today and get a final decision on this if we can get there? between highlights and summary, I would be a minus one on highlights. primarily for the reasons that you mentioned Dimmitri. I'm not making a comment about, I'm not taking position on the priority order, whatever, but I pro presume that it would be in whatever order they provided, if there is such an order, and we can kind of chat more about, if that's something that is a separate flag that we put on each field. plus one to summary.

Manu_Sporny: I think most people will kind of understand, what they're supposed to do there. there can be people that are like, my summary is every single field in the credential and that's a bit of an abuse of the thing, but is allowable and, I don't think we should block on that. So, there have been a variety of other things. I think Coyote mentioned overview at some point. abstract has been mentioned gist all those types of things I think are kind of not as good as summary plus one to summary if we can rename it to that I'd be a pretty strong pro plus one to

Dmitri_Zagidulin: All right.

Dmitri_Zagidulin: Anyone else? Dave

Dave Longley: I think summary has similar problems to highlight similar to… what I mentioned before. it both helps and Summary seems to much more clearly ex exclude any details. just summary is how that reads to me whereas highlights let you highlight whatever you wanted to highlight which summary information might be other things. So highlight felt a little more flexible in trying to cover other things. Dave Longley:

Dave Longley: My main objection to any of these is as an issuer or someone building this I want to know what I'm supposed to put in here and I don't want to feel like I'm abusing it or that if I use it a certain way that no one will have any interest in using it the way I used it. So I'm not looking to just provide an overview. That is one kind of UI component that might be used with how I express this information. I'm not looking to only provide a summary. I'm saying I've organized this data so it is easy for anyone to render this on the screen. Whether they're rendering a summary, an overview, a list of fields that I think are important all the way down as many fields as I want to list.

Dave Longley: If they have a display that can list up to 10, then they take the first 10. If they can do 20, they get all 20. And I've set up the data and expressed it in a way so that they don't have to think about any of that. I've put it all in sort of priority order and that also includes a summary and overview. and I don't know what a good name is to capture all of that, but I worry that…

Dmitri_Zagidulin: Thanks, man.

Dave Longley: if we give it a specific name and we get some of those features, we're not really capturing the whole render method, and then someone will feel the need to invent another On.

Clarity of Render Method Intent

Manu_Sporny: Yeah I don't think a single word will capture everything you just said Dave. So I don't think we can do that in a single word. so I think we should do what we normally do in specs which is explain in pros what we mean by summary whatever. but unless something highlights to me does not have that at least to my understand my view of highlights it does not do the things that you mentioned in your paragraph right so it is not necessarily a good word based on the things that you said that it does.

Manu_Sporny: And I think no matter what word we pick, I mean, plus one to your description of it, I think we should write that down. but I am concerned that highlights does not describe that thing. And in highlights may be much more difficult for someone that is, for example, a non-native speaker to understand versus, summary. and of course, really hard to back up any of these arguments with data because we're trying to figure out how people, understand a single word. so the suggestion is whatever we do, it's clear that that word is not going to, express all of the things we want it to do. And so, we should write it out in pros exactly what the intention is with this field.

Manu_Sporny: And we should make it clear that the concerns, the misinterpretations of that of the word will have clear descriptions about…

Manu_Sporny: what we mean that you can and can't do. that's it.

Dmitri_Zagidulin: Thanks, man.

Dmitri_Zagidulin: So, I want to say plus one to what Manu said that we're unlikely to pick a word that will capture all of the connotations, especially since it seems that where we have several different aspects that we're prioritizing, so to speak.

Dmitri_Zagidulin: For example, one of my points is that prioritizing or highlighting is a much smaller subset of the use case whereas summarizing and the list view is sort of the primary emphasis of this. however given that we have an overview or rather an overall superass template not template sweet render method that has fields in common. We can have a priority field in that overall superass that can be used in any of the suites including this one to prioritize should people find that useful.

Dmitri_Zagidulin: Von and then Benjamin.

Ivan_Herman: So maybe I am one of those people normally referred to as non-native English.

Ivan_Herman: So maybe that's my mistake. But for me the term highlight has a kind of a visual aspect to it. when I highlight a text when I annotate it or something like that which is definitely not the case and that's mainly what bothers me when I hear highlight in this respect. so that's why I'm more in favor of summary. I know that during the discussion we also had at the much more neutral alternative which says data or something like that data extract or maybe it just data it's very neutral maybe that can work as well just to add one more to the mess.

Dmitri_Zagidulin: So I'd like to jump queue and remind folks that data by itself is we don't need it because the verifiable credential is the data. If somebody wants to enumerate all of the fields,…

Dmitri_Zagidulin: they can just do that. They can just enumerate the fields of a verifiable credential. They don't need a special render method for it.

Ivan_Herman: That's

Dmitri_Zagidulin: So it is already data. Go ahead, Benjamin. And then

Benjamin_Young: Yeah. I put selections in the chat,…

Benjamin_Young: but it's kind of based on I actually thought what Abon was going to say was the inverse of what he said. because for me, if I were to have a physical form and hand it to you and say, to use the sentence, select the stuff you want me to care about, I'm probably not going to say select. I'm probably going to say highlight and hand you a highlighter. If I'm tell me what is important for me to care about in this bigger document. If I'm a realtor or a lawyer or a passport agent or any of these people, they're going to be in some way annotate the document and point at the fields. Typically, that's called highlighting. could also be called selecting, but that…

Dmitri_Zagidulin: Go ahead. mono.

Benjamin_Young: then runs us into other weird vagaries. In no case is it So I think summary is right out a bad choice personally because it's reductive from a hole which is not what this is. This is selecting out of a hole. totally open to things that point towards selection and subselection. Not a fan of anything that makes it sound reductive which is very different.

Manu_Sporny: I provided some other options. curation might be the closest one. because a selection doesn't necessarily mean that you're prioritizing order. And from what I heard Dave said, there is a prioritized ordering here. that is explicit. unless we want to take that out. I we have to do that, I mean that's one of the goals of this thing. don't necessarily agree that summary is strictly the definition that you use, Benjamin.

Manu_Sporny: But what I think the problem here is that any single word has a bunch of positives and negatives to it. but seeing as Dave's fine with curation, does anyone else have any strong feelings against it? Curation is you take a set of things and you select among them and you try to specify which ones an individual should take a look at. that's it. Go ahead, Nate.

Render Method Control and Normalization

Nate_Otto: Thanks. I don't think that choosing which things are the most important is the key aspect of this render method that is interesting. sure. Yes, highlights is okay. summary is maybe slightly better. the thing that I was trying to get at when I proposed this method originally was not the selection process of what is the most important stuff to display. It's a type of render method that is where the rendering is still under control of the renderer, not the issuer.

Nate_Otto: It picks data and regularizes the format of that data into a set of fields that are the things that you want to display. Yes, sure it's the most important data to put in front of the user. But the key part of it really was which we kind of have lost by going to highlights. Not that I really care about it that much, but curation takes us even farther from this. the thing we've lost is just the notion that this is a thing that is under control of the issuer. It is not a beautiful HTML interface. It is whatever the renderer wants to make it. And the card was the sort of the main metaphor that was being picked by a bunch of different wallets that were doing these generic renderings.

Nate_Otto: And so the idea was just this is a regularish data structure that you can put into your own template for displaying that data structure and we can fit many different credentials into this type of output shape in JSON. So normalization as Dave says in the chat although that doesn't make for a very good render method name. So I don't really have a solution.

Nate_Otto: I don't really have a lot of strong preferences in this, but hearing curation definitely made me think we were getting farther away from the target than closer.

Dmitri_Zagidulin: All right.

Dmitri_Zagidulin: Thank I want to hop on the queue to say I agree with what you just said that curation doesn't quite have to me it's slightly too abstract and I wonder if we can offer selection as a synonym that is slightly planer and more understandable.

Dave Longley: I did want to strongly plus the concept that Nate was saying that what we want out of this render method is the issuers organizing the data in some way that makes it easy for you to fit it in with your existing look and feel in your application. They're not telling you how to make things look and feel. They're saying, "I've put this into a regular shape. That should make it really easy for you to build your own UI components and integrate this into your own user interface. So I agree normalization isn't great, but maybe words around integration. how do I feel about selection?

Dave Longley: I don't think selection fully communicates this stuff that was just said. It feels like yet another word that is kind of okay.

Dave Longley: And it sounds like you're picking out specific things. that is only one aspect of all these other it doesn't capture any of these other concepts.

Dmitri_Zagidulin: But that is…

Dmitri_Zagidulin: what we're doing here. We are picking out specific things such as what

Dave Longley: And I think it doesn't capture that you're turning something into a regular form. it is true that you're going to part of being able to express a selection in a sensible way is that you're like really what you're doing is you're saying here's a regular normalized shape and I'm selecting what fits in this shape for you and then use that shape to build your UI components. it's something like that and integrate that into your system. But selection on its own doesn't do that. selection might be here's the list of fields and that's it. what does that even mean?

Dmitri_Zagidulin: Mana.

Dave Longley: That's what a selection is to me. So it doesn't capture the rest of everything else that we've talked about here.

Manu_Sporny: I was listening to Nate what you said about the thing I'm trying to figure out now and maybe I've totally misunderstood this the entire time. I thought the issuer was providing a priority order it's not like these things are a random set in and the wallet can just show it in whatever order they want. I mean they can but there is a definite explicit ordering of these things in to least important order.

Manu_Sporny: At least I thought that's what is are we not doing that anymore? I thought we were doing that.

Dmitri_Zagidulin: So I want to clarify that's not quite…

Dmitri_Zagidulin: what we're doing. I think out of all of these what Dave said about normalizing is the key bit here because for example just let's talk specifics. We're requiring a name, meaning any sort of list component, any sort of we're trying to project the full verifiable credential into that's that somebody can say okay the date is priority field number one. That doesn't matter for the use case. We need a normalized name. Go ahead.

Manu_Sporny: Yeah, but I don't know Dimmitri if that answers my question. there is an explicit ordering is there not because if there isn't then how does wallet software know what field to render in what order right as an issuer for example as an issuer and I'm issuing fairly large credential let's say a student transcript as an issuer have a pretty strong feeling about

Manu_Sporny: what I want displayed in what order and the wallet has no clue whatsoever I thought we were trying to get away from that.

Dmitri_Zagidulin: But that's…

Dmitri_Zagidulin: That's what the HTML detail view is to give Yes.

Manu_Sporny: Is it

Dmitri_Zagidulin: to give issuers control over displaying. This view here is to say there is a number of constrained use cases where the things that those constraints use cases have in common is they need normalized required fields.

Dmitri_Zagidulin: for example on a text terminal to display on a v what is it called fed ID browser mediated selector So the normalization is the key here. Mano No,…

Manu_Sporny: So this has no order to it.

Dmitri_Zagidulin: the order can happen, but a priority order can be a superass field that can be used by any render method,…

Dmitri_Zagidulin: not just this one.

Manu_Sporny: I don't know

Manu_Sporny: if anybody else is confused by that, but I'm very confused at this point.

Benjamin_Young: Yeah, I'm completely confused. Demetri has as defined fields is just an array and it says array of custom data fields in display order.

Benjamin_Young: Those are the custom ones. And Nate's here. Nate can tell us where did he drop?

Dmitri_Zagidulin: My point is that …

Dmitri_Zagidulin: if we add a property display order,…

Dmitri_Zagidulin: we can reuse it in the HTML render suite as well as this one as well as any other ones that we come up with Exactly. No,…

Benjamin_Young: So that would be on the render method sorting the entire render method.

Benjamin_Young: Doesn't that widen the scope of what we've been discussing about field ordering or I don't know.

Dmitri_Zagidulin: it just makes it reusable.

Benjamin_Young: I've lost a lot.

Dmitri_Zagidulin: Field ordering is a property that all the suites can reuse is my only point here. So it doesn't need its own separate render suite, whatever this one turns out to be called. It can be

Dmitri_Zagidulin: The field ordering is a useful enough property that all suites should have access to it. Exactly. Display order in shared by all of the suites just content type is shared between all of the suites. Just like all of the fields here Go ahead. Who's next?

Dmitri_Zagidulin: Yeah, all these fields are shared between all of the suites. So, display order would go in here.

Manu_Sporny: Yeah, Demetri, I understand that it's a separable thing. and I am questioning whether it's actually useful in HTML because you have full control like that. the issuer has full control over display order and all that kind of stuff, So, I don't think it's useful in static and it's not useful in The only one where it is useful is this one, but you could argue that maybe there's a future render suite that uses it as well.

Manu_Sporny: But going back to what Benjamin mentioned, currently we do have an explicit ordering and I don't know if we are now saying there is no explicit ordering unless you have a display order. and the reason I'm struggling here is because that part of it kind of matters for the naming maybe. yeah. it feels like we're growing scope while trying to name something. And that's a difficult thing to do because then all of a sudden our core reasons we name the thing are not holding right. We've got to fix some of these things in place in order to pick a word that describes it.

Manu_Sporny: That's

Dmitri_Zagidulin: All right,…

Dmitri_Zagidulin: Benjamin, go ahead.

Benjamin_Young: Yeah,…

Benjamin_Young: I agree with Manu that the scope is widening massively and concerningly and we've lost a lot. At least I did. but I also am hearing us operate on assumptions about render methods being in an order and They look like it at the JSON level, but they're not in actually any order because we haven't defined that render methods are a list or…

Benjamin_Young: whatever in the which means if you shoved them in a graph and got them back out, you can't guarantee that order is going to be consistent.

Dmitri_Zagidulin: Just to be clear,…

Dmitri_Zagidulin: we're not saying render methods themselves are in order.

Dmitri_Zagidulin: We're saying the fields within this form artist formerly known as card here.

Benjamin_Young: I haven't right.

Benjamin_Young: There's just JSONLDD stuff to turn that array into an order thing is all I'm well.

Dmitri_Zagidulin: And we could that's a trivial fix.

Benjamin_Young: Yeah, but we have also been operating the render methods are in some sort of priority order.

Dmitri_Zagidulin: I don't think anybody has though.

Benjamin_Young: Maybe not on this call, but we have historically. so I'm just calling it out that if we want order, we need to do it some way. It could be with a field like you mentioned, but that's on top of three or…

Benjamin_Young: four other potential options for saying the array is ordered. yeah, just wanting to highlight the fact that arrays even…

Dmitri_Zagidulin: Make sense?

Benjamin_Young: if we say in the pros these are in an order unless we do extra technical plumbing to make sure they are. That was it.

Dmitri_Zagidulin: Makes sense. we'll make sure to remember the technical plumbing. Mono

Manu_Sporny: I'm wondering if we need to fall back to a rank choice, ordering of these options among us and then, the VCWG or CCG or whatever, which is how we tend to pick things if we don't seem to be converging. in order to do that, we do need to suggest what this thing is trying to do. Dave provided four items there. so typically we need a description of what the thing is trying to do and then we need a list of options for people to rank choice. I don't know…

Manu_Sporny: if folks feel that we're there or if we feel like if we keep talking on this call we'll converge on something.

Dmitri_Zagidulin: So to address Kyote's question in the chat Coyote is asking…

Dmitri_Zagidulin: if we had a field like display order wouldn't it remove the need for this render method? No because ordering the fields is not the only thing that this render method does. It also normalizes. That bit is key. Again, recall how this got started. most of the current mainstream wallets ha have this notion of a card. we went through the fact that it's very skeomorphic that it may change in any number of months or years.

Dmitri_Zagidulin: But the reason that the wallets have settled on this is to solve the need for this use case of a small subset of normalized fields. And notice by the way with with cards the issuer doesn't get to pick priority. they normalize it. They pick here's the background color, but it has nothing about priority. So, we are trying to fit two very different use cases into one render One about normalizing and the other one is about sorting the field in priority order.

Dmitri_Zagidulin: I like what man has said about putting together a rank choice of suggestions to the field provided we can agree on the purpose of the suite and…

Dmitri_Zagidulin: I like Dave's items except for item three. Dave, go ahead.

Dave Longley: right? Trying to get to agreement on…

Dave Longley: what we're trying to accomplish. so we had those four items I wrote down. the other thing I've just generally been thinking about is that I think we're trying to take NEVC and plug its data into slots where slots are about some meta shape that is easily reusable and pluggable in anyone's interface. So this isn't really about the data itself. there's some basic set of meta shapes that we're coming up with summaries. we've talked about some kind of summary which is a name and a description or something for the VC maybe a picture an image and then individual fields which themselves have names for the fields and things like that.

Dave Longley: And so we're really describing some set of metadata about the VC and slots where those things plug in. so I'm just trying to describe what we're looking for and…

Dave Longley: hoping that that triggers some additional names or feedback.

Dmitri_Zagidulin: Thanks Dave.

Dmitri_Zagidulin: So actually providing field labels is another item to add to. So if I had to tweak dates for items, it would be normalization, priority order, labels, and summary information. I think falls under normalization. So I think those three things

Manu_Sporny: I mean in color, it's we have to describe this thing to people that have not been here and aren't thinking deeply about this.

Dmitri_Zagidulin: that's under normalization I think.

Dmitri_Zagidulin: Yeah, good point.

Manu_Sporny: So I think we're going to have to be a bit more explicit than normalization. or we have to spell out exactly what we mean by normalization it is a summary name description and icon along with a set of fields that each have a label and a value driven by the data in the verifiable credential. so that's really item one.

Manu_Sporny: That's what we mean by I guess a regular shape. prior to orderer and…

Dmitri_Zagidulin: Yeah. Dave…

Manu_Sporny: then ease of integration into renderers UI is kind of a subset of the label and value items. yeah, I get what we mean by the list, but that list needs to train be transformed into something that people that don't have a very loose idea about what we're trying to do

Dmitri_Zagidulin: what about the go latest three goals that I mentioned that's very concrete for the developers and other people can

Dmitri_Zagidulin: Send.

Dave Longley: So, I think if we set out So, first of all, I disagree with the goal of trying to put all this together in a short enough email for people who are not here to then pick names to go with it. I think that's just going very easily could give us a bad name. I agree with the goal for us here to come up with exactly what we want this thing to do because I think even in this conversation some of us have learned more about what other people were thinking in this group. so I think we should continue this exercise but I don't think the end goal should be to then send out an email with a really tur list. anything longer I think is going to be hard for anybody to read where people don't have the rest of the context or things we might have forgotten to then go vote somewhere.

Dave Longley: I think we internally should get a better idea of everything we think this render method should be and we might find that the name reveals itself from there and if not then we can pursue this other method.

Manu_Sporny: Yeah, I'm fine. The issue is everyone on this call has minus one, at least one of the things in a fairly strong way. as far as I can see. so, rank choice is typically the only way to get past that. Otherwise, we're just going to go into a death spiral of trying to pick a name.

Manu_Sporny: And everything being minus one. plus one to Dave to your, let's write it down. But, I think did we have you and Dmitri disagreeing on the goals? I think I can't track.

Dmitri_Zagidulin: are we…

Dmitri_Zagidulin: though because I think at this point there is a bit of convergence. yeah.

Manu_Sporny: So, let's write it down because it's not clear to me. it sounds like both of you are disagreeing to me.

Dmitri_Zagidulin: Yeah. Mano, u just to address you're absolutely right that if this was just about naming everybody minus one's rank choice voting is the only way to get past that but in order for us to present a rank choice vote list we need to be clear about what the goal of this render method is which is the bit that we're possibly converging on.

Dmitri_Zagidulin: So this has been actually really helpful and productive Dave. the three goals normalization with a specific items, field order and labels, do those capture all of the emphasis that you want or do you feel something is missing?

Dmitri_Zagidulin: Okay, so Dave's three items regular shape. Go ahead.

Dave Longley: Yeah. …

Dave Longley: So, I was typing what I think my items are to try and compare that to your goal. Then I put that in the chat. So normalization I think is in common it's a regular shape and the main reason for that is as a renderer you just want to grab a bunch of stuff and stuff it into slots. You don't want to be thinking about the VC specifics at all. So that's what the normalization is for. That is to enable you to easily integrate it into one of your components. there's some regular meta shape that you can grab stuff and plug it in. it is good for the issuer to list out fields in issuer priority order and provide field metadata. So, this is things like labels. There might also be icons or other things that go with individual fields that could be useful for people and you could include that information.

Dave Longley: And again, that's just more metadata about the fields so that if anyone has a field display, they can plug it in there. And the fact that it comes in priority order means it makes it easy for you to know which things to show first, even if you have a scrolling thing or something that might show more or whatever. and then there's summary information which I have separated out from the regular shape. it does fit into a regular shape but it's important that it's summary information about the C type the name that you might display for that credential that name might appear in a variety of different languages as well and so I separated that as its own metadata category about the VC type information and…

Dave Longley: so those are the three things that I think that this render method is trying to provide …

Dmitri_Zagidulin: Can you say more about VC type?

Dmitri_Zagidulin: What does that mean? That seems weird.

Dave Longley: is it a driver's license? Is it a birth certificate? Is it this or…

Dmitri_Zagidulin: But that's literally VC.ype I failed…

Dave Longley: that? and…

Dmitri_Zagidulin: which we already have as nothing.

Dave Longley: no, it is. No, it's not. VC.type field is a URL it's a component of a URL. And that is not sufficient for someone who doesn't know someone who's writing an interface who one doesn't know how to go fetch that URL and then read RDF labels about it. or someone who doesn't know whether or not they should take a string that is in some context and apply a normalization to split it on camel case or…

Dave Longley: something on B that information is simply external you either have to go fetch it and know to follow your nose or it would be provided in a render method. So type is totally insufficient for that on its own.

Dmitri_Zagidulin: But this is a new feature that you're talking about.

Dmitri_Zagidulin: Do you mind outlining it in a separate issue?

Dave Longley: When I say I don't think this is a new feature. I don't remember…

Dmitri_Zagidulin: is a new feature because we haven't heard about this before.

Dave Longley: if we go to card render suite. I don't know that we haven't heard about this before. It's been discussed in the issues around this render method. But if you were to perhaps click on card render suite, I don't remember if there's already something in there that talks about this name and…

Dmitri_Zagidulin: There is not we're looking at it here.

Dave Longley: description. I think name will pro probably be used for exactly that.

Dmitri_Zagidulin: But name is not type.

Dmitri_Zagidulin: name is just So if you just mean name that's fine you're right name has been in here from the start. So it sounds like we are converging normalized shape with specific field order and labels monos. I mean I would ask to tweak…

Manu_Sporny: So is one, two, three there correct? is that what everyone believes we're creating here? Because would anybody object to what Dave wrote in one 123?

Dmitri_Zagidulin: because in Dave's list one and three are very similar regular shape is the summary information.

Manu_Sporny: I think it means is regular data shape, right? Meaning you have to have input into a processor and one is more about regular data shape. Where is three one is for machines three is for humans.

Dave Longley: One is saying the data shape is regular. You take any VC and you will end up expressing this information about it in this specific shape. Three what is some of that information that might not even be present in the VC itself…

Dave Longley: which is name and description of the type of VC. So one is about saying that you want to shape things a certain way that and…

Dmitri_Zagidulin: I'm not sure I fully understand.

Dave Longley: that is a separable concept from okay what are you going to put in the shape? How many corners is it going to have?

Dmitri_Zagidulin: But I think when describing this to developers and the list, we can just combine those two. I think that's getting too fine grained.

Dave Longley: We could combine them all into one big list. But I think it's useful to have it to separate out the concept of summary information from for example fields and…

Ivan_Herman: Perfect.

Dave Longley: from the fact that it's a regular shape. I feel like those are three independent ideas.

Dmitri_Zagidulin: A regular shape is too abstract though. that's too abstract. can we say what we mean by regular shape? Can we specify the shape?

Dave Longley: Maybe what we would say is every VC has its own data model behind it and its own expression that could be anything at all. And the whole idea is to normalize that to a common shape that's really useful for rendering. And so it is the issuer's job to take any arbitrary shape that the VC is expressed in and turn it into this singular shape that is the only shape that the renderer has to %.

Dmitri_Zagidulin: Go ahead.

Manu_Sporny: Yeah, I think it's more about data structure. number one is a concrete data structure for the purposes of rendering, And it's probably more specific than that, but Three is about, human readable information,… summary information. Regardless of shape,

Dmitri_Zagidulin: In any case,…

Dmitri_Zagidulin: those are fine grain details. I'm not hearing any major objections to these three. does anybody feel that some of these three goals are missing an important item disagrees with one of them? Let's gauge convergence here.

Dmitri_Zagidulin: Thank. Excellent.

Nate_Otto: As we mentioned earlier, I think the branding information, the sort of color that the issuer selected is one possible additional category that we're subsuming into a regular shape. And I don't mind at all, but it is subsumed there. This seems fine.

Dmitri_Zagidulin: So let's see. Let me write things yields in priority order with labels summary whatever that means.

Dmitri_Zagidulin: Still not clear what you mean by summary as opposed to a regular shape though Dave.

Dave Longley: Yeah, but that's because regular shape now has icon name and description in there and that is not relevant.

Dmitri_Zagidulin: We need to specify though.

Dave Longley: I think that's saying the concept of regular shape is you take any VC and it will have the same shape. You only have to understand one shape as a renderer. That does not say…

Dmitri_Zagidulin: But then here you've described the concept of a render method.

Dave Longley: that doesn't say what the shape is. And then in some sense I'm trying to map that to an HTML render method.

Dmitri_Zagidulin: the words that you just described. That's a render method.

Dave Longley: It is not the same. An HTML it does surface that a specific shape for the HTML render method but the rendering itself and the information that's in there is not exposed to you as a renderer. it is totally opaque. So you put this in a sandbox and something will show up the end. That's very different from here's exactly what you can go render.

Dave Longley: Here's all the information in a single shape and you can always expect it to be in this shape. Now you go decide how to render that. That's quite different.

Dmitri_Zagidulin: Wait. So we are diverging though.

Dmitri_Zagidulin: You're saying we don't want to specify the subset of the fields in this render suite.

Dave Longley: I did not say that.

Dmitri_Zagidulin: We don't want to specify icon and background and

Dave Longley: No, I did not say that we don't want to do that. I'm saying those are the specific things that is The fact that we want a single shape is itself important to highlight. If I just hand you a VC, it could be in any shape. And now you have to know the VC type or you have to have a generalized processor that can do the normalization yourself for your own interface. we're eliminating the step where you need to do that by having the issuer do that.

Dave Longley: The issuer is going to offer you a normalized shape. That's a different item in our list. Here's what's going to be in that shape.

Dmitri_Zagidulin: Got it.

Dmitri_Zagidulin: So, let me see if I can Okay.

Dave Longley: name, description that's summary information about the VC. What else? Fields in priority order, etc.

Dmitri_Zagidulin: So, would you say Mon just pasted? Does that capture what you said? Excellent. Does anybody else feel that's missing something or…

Dave Longley: Yeah, I think so. the only thing that I think is that's missing in one is there's no mention of normalization or…

Dmitri_Zagidulin: object to that? Go ahead.

Dave Longley: it does not say that every date JSON data structure will be the same. that's really what we're trying to do and that's what normalization does or…

Dmitri_Zagidulin: How about a normalized JSON data structure?

Dave Longley: if we don't want to use the word normalize we can say no let's use that word I guess normalize to a single JSON data structure

Dmitri_Zagidulin: Does anybody object to this format changing rather concrete to normalized once twice the exact was this …

Manu_Sporny: I'm trying to retype it out. What was the exact the VC? okay.

Dmitri_Zagidulin: what I just typed? Yeah.

Manu_Sporny: You typed it out. Okay. All right.

Dave Longley: Yeah, I had previously captured things like colors using the word style. but it's I mean, style is a little more specific because you might want to separate out which color goes where and so on. But go

Dmitri_Zagidulin: Got it.

Manu_Sporny: The thing that Yeah,…

Dmitri_Zagidulin: And we can tweak the exact fields. Go ahead.

Manu_Sporny: the thing that threw me off with that, Dave, is you put it on the fields list, which doesn't specify style information other than maybe language if you want to view that as a style, which probably shouldn't.

Dave Longley: I don't know what we I could imagine that an individual field might also have metadata an icon which might imply it has some other style as and so I just put it there as a catch all.

Manu_Sporny: Note Are we doing that for version 10? Because if we are, we should put it in here, I'm concerned that Okay.

Dmitri_Zagidulin: L. Okay.

Dave Longley: I think in this conversation we can write it down and then we can weed that

Dmitri_Zagidulin: But I'm still not hearing any major objections to these three items. So This is progress. that then we'll capture this in the issue and…

Dmitri_Zagidulin: or the PR and I'll make a concrete proposal for the next bill. Benjamin, go ahead.

Benjamin_Young: Yeah, in the spirit of concrete proposals,…

Benjamin_Young: I've spent the last half hour trying to rebase that PR.

Benjamin_Young: It's not worth the lift cuz There were quote unquote editorial changes that massively shifted the corpus in the last six months of us bike shedding this or…

Dmitri_Zagidulin: Yes. Yes.

Benjamin_Young: three months or however long it's been.

Dmitri_Zagidulin: Yes. We can just redo them.

Benjamin_Young: I guess it's only been two weeks,…

Dmitri_Zagidulin: Yeah, sounds good.

Benjamin_Young: but whatever it shifted. So yeah, the amount of work that's actually done in here is easier to redo than it is to replace. Yeah. So,

Dmitri_Zagidulin: Okay, so we can close this PR and so We have the goals. We have these three items.

Dmitri_Zagidulin: We just need a sweet name to fit them. And there if we don't have consensus, we can go to rank choice mode to the list. but it's the goals alignment part that's important. All right. I think this is a good place to stop since we're close to the top of the hour. Ivonne, go ahead.

Ivan_Herman: Just to your last comment, in my view the most important thing is to create a PR which captions all these things and…

Ivan_Herman: we can leave the card the naming is a question mark once everything is really described there. Don't worry about the name for the time being in my view.

Dmitri_Zagidulin: Can do yeah,…

Dmitri_Zagidulin: we can do that. thank you so much I appreciate everybody's patience. This is a finicky but really important issue and I think we're close to having something where we can all live with. in that case, see you all next week at the same bad time and bad channel. Cheers all. Meeting ended after 00:59:08 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.