Meeting minutes
Meeting Introduction
Dmitri_Zagidulin: Welcome we're going to give it another few minutes for folks to join. We'll get started.
Dmitri_Zagidulin: All right, three minutes after might as well get started. So, welcome everyone to the weekly random method task force of the W3C verified credentials working group. as always we're under the W3C code of conduct and IPR regime. you need to be a member of the group to contribute etc etc. let's see am I forgetting anything else from boilerplate? I think those are the main things.
Dmitri_Zagidulin: So during the last couple of calls, we started working on the threat model brainstorm which is over this URL here. I'll put it a chat in Google meet chat. Although also let's see do we usually use an IRC room for these task force meetings.
Dave Longley: No. so you just need to put it in this Google chat and…
Dmitri_Zagidulin: Okay. …
Dave Longley: the Google chat is now saved.
Dmitri_Zagidulin: Got it. So I will share screen also for convenience.
Dmitri_Zagidulin: All So hopefully everybody can see that. Yeah. So we ordered in our usual brainstorming method where we put a bunch of sort of parking lot implementation and dependency threats. these are these items.
Render Method Strategy Discussion
Dmitri_Zagidulin: there below. And now need to move the uncatategorized threats these 15 items through the categories. We need to categorize them as external threats, as dependency threats, implementation and so before we dive into that, so in terms of pull requests, we don't have any new pending ones because everyone I think is waiting to see the resolution of the discussion of given our limited time in the working group charter, how few render methods can we get away with shipping?
Dmitri_Zagidulin: And during previous calls the several points of view have been brought up from I think mom and Dave was the proposal that we only ship the sandbox iframe app method. and for myself what was the sort of counterp proposal that we don't start with that we start with the templating method to which I think it was Benjamin who brought up the question of what are we going to do about special functions such as date formatting.
Dmitri_Zagidulin: It was also during the discussion the point came up that we at the very least need separate methods for rendering credential detail views and a separate more lightweight method likely the quote unquote JSON card approach for the list view right so that at the very least if we do nothing else within the scope of this task force of their credentials working group charter. We need to ship at least two things. Something that addresses the list view and something that addresses the detail view. And then we're continuing sort of the discussion of what's the minimal amount of methods that can cover those two things.
Dmitri_Zagidulin: And what further came up in the conversation was okay in order to decide between the Pambox iframe approach and the template substitution approach let's look at the security and feature tradeoffs of those two methods which is how we got to the render method threat modeling exercise. Aside from the fact that I think a lot of the VC working group task forces are going through this exercise right now anyway.
Dmitri_Zagidulin: I think that sums up the story so far. If I missed any important details, please jump in.
Dave Longley: Yeah, I don't know that you missed anything, but I wanted to be clear that my position in right now is that I think we need three render Something for view data. This is sort of the JSON card rendering case where the render will pick all the styling and whatever else to fit it in with their UX but they want the prominent data fields that the issuer would like to show up and then we have sort of an NFC binary payload case and then finally we have the HTML case. that's my view that we have those three things and I think the HTML case can also be used as a sort of data export get some rand renderer code will run in a sandbox and…
Dave Longley: output some kind of binary format like a PDF. So no.
Dmitri_Zagidulin: Got it.
Dmitri_Zagidulin: Got it.
Dave Longley: Yep.
Three Required Render Methods
Dmitri_Zagidulin: So, let me just that I remember the three were the sort of rendered pre-baked methods like the NFC binary.
Dave Longley: And then there's a view data.
Dmitri_Zagidulin: The Yep.
Dave Longley: We need a better name for this. there's a PR called JSON card. I think that's too specific to a particular That's that thing. that's, just a transformation from a credential to data that, prominent fields that you would put in a display of some kind, lists, cards, whatever else that you style yourself. There might be style hints in there that are helpful, though. And then which is single I consider this to largely be a single credential display totally customized by the issuer using whatever HTML they want. And it also covers the case of outputting you put something into this HTML sandbox and…
Dave Longley: you can get out like a PDF.
Dmitri_Zagidulin: Got it.
Dmitri_Zagidulin: So looking at those three, I personally completely agree. I'd love to hear from the group if we have consensus unleashed on this statement that we need these three things. does anybody else object or desent? So, I see plus one from Ivonne and parts. major objection. All right. So, at the very least, let's start with the easy case.
Dmitri_Zagidulin: I think we all agree that we need something pre-baked like the NFC method or even heaven for send a pre-baked static image for whatever super limited display clients that can't do HTML but just if you give it an image it'll display it. so that's the good news. That means we can start working on PRs to finalize that method. I suppose we need a better name for this. We maybe need a final name for this. We need a consensus name for this method for the static pre-bake method.
Dmitri_Zagidulin: Let's take a look at our stack real quick just to see what it's currently called if anything. Okay. So we don't Okay.
Dmitri_Zagidulin: So we have this thing called the.
Dave Longley: It might be Yeah,…
Dave Longley: it might be a listed as a render suite.
Dmitri_Zagidulin: So, if I'm understanding the conversation so far correctly, and if nobody objects, I would propose that we generalize this, right?
Dmitri_Zagidulin: Instead of calling it an NFC render suite, we parameterize it even further by calling it a pre-rendered and then have another parameter called content type or something that determines the content type of the actual payload of the template.
Dave Longley: Yeah, I feel like there's an open issue or…
Dave Longley: About doing this. I think we were going to Yeah,…
Dmitri_Zagidulin: Don't think there's a PR,…
Dmitri_Zagidulin: but let's look at the issues.
Dave Longley: maybe it was in some demo code as well. I think there was the concept of either the render suite would be called static and there was a mode for NFC or audio video. there was some other mechanism we had that was doing a better job of generalizing
Dmitri_Zagidulin: Yeah. Yeah. Yes.
Dmitri_Zagidulin: Yes. If I vaguely remember this,…
Dmitri_Zagidulin: but let's actually see if we can find handling record. Yeah, it's not currently. Yeah, go ahead.
Ivan_Herman: Just one of you two could explain…
Ivan_Herman: how exactly this works in practice.
Dmitri_Zagidulin: Absolutely. So the way it would work is at issuing time or before that the issuer renders some way they want to output a credential. For example,
Dmitri_Zagidulin: this is a binary blob that's going to get transmitted via NFC and we have a separate credential method NFC task force that is doing the exact format of that binary block but the point is by the time it gets to the VC method it's just an octet stream yeah go ahead
Dave Longley: Yeah, that we might want to ground this in a concrete use case. This would be something like giving the digital form of a ticket to get on a train pass and they could go buy a train scanner and pass their phone over it and…
Dave Longley: that thing your phone would know how to use the render method to pull out the exact NFC payload to so it's generally for that sort of use
Dmitri_Zagidulin: So, does that make sense?
Dmitri_Zagidulin: So, issuer renders or bakes one or more of an NFD offset stream, a pre-rendered PNG image, a wave file or an MP3 file of an audio description, something that the consuming client, the wallet, so to speak, does not need to change. It can just display it or play it back or transmit it as is.
Dmitri_Zagidulin: If go ahead on the queue right so part of it is the question of generic versus specific meaning specifically for barcode there could be their own method…
Ivan_Herman: Yeah. I understand that the reason…
Ivan_Herman: why I was wondering about without stirring up too much mud. But what's the difference between doing it this way and use the simple barcode method which we define elsewhere? What the relation between these two
Dmitri_Zagidulin: but what about a general purpose this is a rendered PDF of the certificate that this represents.
Ivan_Herman: You are looking at one direction. I was looking at the other direction…
Ivan_Herman: which what I was saying is that the generation of a barcode is one of these
Dmitri_Zagidulin: …
Dmitri_Zagidulin: So I see Benjamin has hand up.
Static Render Method Discussion
Benjamin_Young: It's fine.
Benjamin_Young: I didn't know if Avon was headed here, but we do also have related resource as a static stuff. but as yet that's all unidentifiable bag of things. so maybe there's just some plumbing here to say, use this related resource also in the payload as a render method. and then we get all our semantics from related resource because if it's just a static blob, we already have all that plumbing
Ivan_Herman: Okay, we can leave it for later. But at some point in time, I am always wondering about…
Ivan_Herman: how the different specification relate to one another. That's something that we have to get a proper story around that because for the time being it's not clear.
Dmitri_Zagidulin: You're absolutely right.
Dmitri_Zagidulin: And I would love for the barcode task force folks to weigh in on this because I'm not as familiar with it as I'd like to be, but it's a good question. You're right. we do need to figure this out if nothing else than for consolidation reasons. But aside from figuring out whether or not let's say this static PDF render method can also fulfill the simple barcase use case.
Dmitri_Zagidulin: Aside from that, Ivonne or anybody else, any objection to a general purpose static render suite,…
Ivan_Herman: This
Dmitri_Zagidulin: so instead of an NFT being a top level render suite, we have a top level static and then the NFC would go into a second parameter that's like content type or…
Dmitri_Zagidulin: or usage or whatever. Go ahead. venture and
Benjamin_Young: Yeah.
Benjamin_Young: Yeah, we've been down this road before and cracked our heads on some unexpected glass ceilings. I think we should go down it again because we keep, coming around the barn and the door's still there. but there were complaints, concerns around modeling it tangled up in template language and then trying to undo that and extract it kind of in the way that you're describing u other modeling concerns or fears or whatever. so what I'd love to see is us do exactly as you described,…
Benjamin_Young: try again and see if we end up with the same set of proposals that we had last time. and then if we do then we address them properly this go around. but if anybody wants to muck around in the issues there is a whole lot of prior art that points the direction you're pointing
Dmitri_Zagidulin: Got it.
Dmitri_Zagidulin: Got it. But it sounds to me though that most of the friction was dealing with the template part which may be we may encounter less of that if we look at this just from the narrow scope of static dates. You have to hand up.
Dave Longley: Yeah, I don't know how easily you can see the chat, but I also pasted in there another working example of another way to model it. Dave Longley:
Dmitri_Zagidulin: Apologies like not equally.
Dmitri_Zagidulin: Let's look. Okay. So
Dave Longley: And then maybe it was in the HTML PR. I'm looking to find we've used output preference before and mode and things like that as fields that for example digital wallet would be looking for based on the current user experience they're working with. They might be looking for it's an NFC task or…
Dave Longley: it's an audio video task or whatever it is. they might look for matching on render methods based on that output mode that the render method prefers.
Dmitri_Zagidulin: Got it.
Dave Longley: And…
Dmitri_Zagidulin: Got it.
Dave Longley: then the static thing in as a literal template as opposed to a template that you replace things in.
Dmitri_Zagidulin: Got it.
Dave Longley: But it still has render property in there. So that you could do some analysis. you would assume based on what the issuer has announced that the properties in the render property what would appear in that static template even if there is no template processing.
Dmitri_Zagidulin: So, overall, I really like this approach. I think this is great. Exactly what we're looking for. minus possibly we need to rename from template to static render method.
Dmitri_Zagidulin: But that last part that you said that it's the responsibility of the consuming client to introspect the pre-baked payload and make sure that it matches That seems a little rough.
Dmitri_Zagidulin: Go ahead.
Dave Longley: No, I'm saying the opposite of that.
Dave Longley: I'm saying you would have to trust that the issuer is going to announce the rendered properties,…
Dmitri_Zagidulin: Okay. okay.
Dave Longley: which you could still use those rendered properties to tell a user this is what's going to be sent in the data. But you'd have no way as a wallet, …
Dmitri_Zagidulin: Got it.
Dave Longley: yet if you somehow knew how to read that template, you could do it. But that would not be the expectation. the issuer has said these are the properties that will be sent if you use this render method.
Dmitri_Zagidulin: Got it. go ahead.
Ivan_Herman: But then the property is not template.
Ivan_Herman: It's value or whatever we call it.
Dmitri_Zagidulin: Yes. Yes. It would be pre-rendered bundle. It would be literal.
Dmitri_Zagidulin: Yes. Yeah. So not template.
Ivan_Herman: So the property change the property as well to something whatever we know you go down the last one the template property
Dave Longley: So we should leave this as is because there have been people who have suggested that we should keep it general and…
Dave Longley: we can do a second JSON that calls it static render method and changes the name template that has different proposals but I No,…
Dmitri_Zagidulin: Whoa, wait,…
Dmitri_Zagidulin: leave it As is this thing right here.
Dave Longley: I mean you edit as is I meant from what was pasted into the chat.
Dmitri_Zagidulin: Okay.
Dave Longley: So, if you go back to your notes,…
Dmitri_Zagidulin: Yep. Got it.
Dave Longley: instead of changing it to say static, let's yeah,…
Dmitri_Zagidulin: Got it. Yeah. All right.
Dave Longley: let's leave it like that as one proposal.
Dave Longley: And then we're editing live the proposal to change some names around. And there are pros and
Ivan_Herman: Okay.
Ivan_Herman: I get that what you do. Okay. But…
Dmitri_Zagidulin: Got it.
Dmitri_Zagidulin: All right. and then Demetri is saying, "How about we rename template to static like this? do we want to make two separate PRs?
Ivan_Herman: then you should also rename the template property. the last line.
Dave Longley: Yeah, line 71 he's in
Dmitri_Zagidulin: I see it. Got it. template to static and templates to payload. Thank you,…
Ivan_Herman: Yeah, Coyote is on the queue.
Dmitri_Zagidulin: Okay.
Dmitri_Zagidulin: So, do we want to make this two separate yards with these two sort of computing methods? Does that seem like a decent idea? All right. Dave, do you want to or anybody who wants to volunteer to make the template method? Coyote. Okay.
Dmitri_Zagidulin: Go ahead, Coyote. Yeah,…
Kayode_Ezike: Yeah, sorry.
Kayode_Ezike: I just had a quick question. Isn't a static render method redundant with literal as suite? wouldn't we always expect those two to be the same if that's what we're literally supposed Yeah,…
Dmitri_Zagidulin: but where's the literal under sleeve.
Dave Longley: So the render suite is handling this difference in it being static versus dynamic. So if you go the render suite line 61, this is mirroring what it was done with the crypto suite properties in the data integrity work to avoid creating extra classes. and having the overhead of people doing extensions on classes rather than extensions through suites.
Kayode_Ezike: I guess my question is would there ever be a nonliteral static template?
Dmitri_Zagidulin: All right.
Dave Longley: I don't think there would be. So I literal is meant to cover Yeah,…
Kayode_Ezike: That's where I was confused.
Ivan_Herman: That's true.
Kayode_Ezike: Wait. I missed that. Hi.
Dave Longley: I agree Coyote. Literal is meant to cover the fact that it's static. So if we're going to rename it to static render method and introduce a new class, we're really getting rid of the suite component of it. we're using different ways of trying to express the extension capability and…
Dmitri_Zagidulin: Yeah.
Dave Longley: we should pick one one way and we could do this through classes or we can do it through the render suite. we had a lot of learnings doing it through classes. if we're expecting to be many of these is problematic. If we don't expect there to ever be more than three, maybe we can have three classes and live with that. But we might be better off with having one class that does the extensibility through the render suite.
Dave Longley: And payload might just be a better name better to cover whether it's a template or not.
Dmitri_Zagidulin: …
Dmitri_Zagidulin: let me see if I capture what you said. you're saying we need to decide on whether we're dispatching off of the type for these three different methods, let's say, or is going to be the same for all of them and we're dispatching off render suite. Is that what you said?
Dave Longley: Yes. Maybe this should just be a sweet render method.
Dmitri_Zagidulin: Right.
Dave Longley: That's a terrible, terribly long name though.
Dmitri_Zagidulin: … Dave Longley:
Dave Longley: And invon has his hand up. Got another Y to that.
Dmitri_Zagidulin: Ivon, go ahead. Yeah. Good morning.
Ivan_Herman: Yeah. now that we turn this into some sort of a more static thing…
Ivan_Herman: then what was a template is now payload then I don't see why we have output preference NFC blah and then payload on a different level I mean that means the payload is a fixed thing whose media type is octed string and maybe mode is NFC these three information are on the same level as far as the rendering is going. it's not output it may be as simple as saying that the payload should be a property for output preference and not as it is right now or that we don't need output preference but we just need information about the static output that we are creating here.
Dmitri_Zagidulin: I agree.
Dmitri_Zagidulin: That's a really good question.
Dave Longley: Yeah, I think we might want to bring in…
Dave Longley: what the HTML render method looks like so that we have an another it's in the spec today. So, you can copy if you keep going down. Yeah, this one has output preference and it looks like mode was renamed to vis to access mode.
Dmitri_Zagidulin: Uh-huh.
Dave Longley: So, I'm going to grab this whole render method so we can compare those two and…
Ivan_Herman: But I think the access mode was for accessibility reasons,…
Dave Longley: what reuse we would get for
Ivan_Herman: wasn't it? it was patterned after some terms that are used in the accessibility world for access mode.
Ivan_Herman: So we should not bring these two too close together because they Apples and oranges here.
Benjamin_Young: I yeah we should at least reference that spec…
Benjamin_Young: which I think is referenced in the draft currently because if in the use of that word it would be something like tap or something for NFC not the current technological implement Presentation of the action of tapping.
Dmitri_Zagidulin: Mhm.
Dave Longley: Yeah, this might just be the wrong name for it and it instead should perhaps be tap. I do think we have a similar fruit, whatever this is. so I do think we need to have output preference. That's a signal if you're thinking about when you're providing a user experience, you have some sense of what user experiences are available or what the current workflow is that in some application.
Dave Longley: you're going to want to filter on render methods that match that workflow. And that might be access mode. And if you're looking for NFC situation, you would look for tap rather than NFC.
Ivan_Herman: But isn't that correct that you can have several output preferences and…
Ivan_Herman: therefore you can have several payloads depending on whether it is an NFC message. It's a QR code. It is whatever else.
Dmitri_Zagidulin: Wait. That's a great question. So, how would it be modeled if the same VC had two different ones? Let's say it had a static and tap one and a HTML templated one. To me the yes agreed.
Ivan_Herman: I think… Dave Longley:
Ivan_Herman: what the render method property in the type allows for several render methods…
Dmitri_Zagidulin: Rather than several payloads or several output preferences. So I agree.
Ivan_Herman: but then the output preference is not a okay Yes.
Dmitri_Zagidulin: I agree. So you're saying why nest it?
Dmitri_Zagidulin: Why not put these things peer level? I agree I don't think we need to method.
Dmitri_Zagidulin: Do any reason why we wouldn't just put these things both for the template and the static pier.
Dave Longley: The first reason is to be clear that it's about the output preference for the render method.
Dave Longley: When the issuer was creating this they were saying the preferred way to get express output is with these things. if we and just have style and access I mean maybe these don't all work well together. putting style at the top level of the render method might be awkward.
Dmitri_Zagidulin: All right.
Ivan_Herman: No, no,…
Ivan_Herman: no, no. we are not talking about the HTML one.
Dave Longley: It right, but we are trying to bring them together and some of this is getting confusing because we've still got type static render method with a render suite of literal.
Dave Longley: Either we're bike shedding and working on a design for something that uses render suite and the type is a more generic name or we're doing something else entirely. I'm not at this point.
Ivan_Herman: My understanding is that we are talking looking at the static render method exclusively.
Dave Longley: I'm not sure what we're doing.
Ivan_Herman: The HTML just came in as an example, but I think it's not a good example here. And we are doing something which is supposed to be simple and…
Dmitri_Zagidulin: But I…
Ivan_Herman: and
Rendering Method Field Nesting
Dmitri_Zagidulin: but I agree with so Ivon I hear you that we're looking specifically at the
Dmitri_Zagidulin: But I agree with Dave that ideally all of the methods static, HTML and the list view should all have similar structure. Hence trying to align it.
Dmitri_Zagidulin: But I also agree with you that for example media type in the output preferences. It should be top level. go ahead whoever's on the queue.
Benjamin_Young: Yeah, I think I'm next.
Benjamin_Young: Can we render sweet literal out of online 61?
Benjamin_Young: Take that out because I think that was one of the things Dave was saying. It was unclear about which way we're going. yeah.
Dmitri_Zagidulin: I see.
Dmitri_Zagidulin: I see. yes. It sounds like we should decide. It sounds like Yeah.
Benjamin_Young: Hang on. we should decide that if that's not what the group wants. versus just take it out. But you also just put media type on the main object, but it's already in payload unless there's some sort of transformation happening,…
Dmitri_Zagidulin: Yeah. …
Benjamin_Young: which would then mean it's not static. I think we need to be clear about…
Dmitri_Zagidulin: there's agreed and…
Benjamin_Young: what each handle is for and what audience the affordance is for. and…
Dmitri_Zagidulin: specifically you're right that we don't want duplication.
Benjamin_Young: then Yeah. Go ahead.
Dmitri_Zagidulin: On the other hand, there is a strong argument for duplication because the consumer for this field is the wallet itself trying to switch off you're trying to pick the right random method for the job.
Dave Longley: Yeah, I want to speak to that.
Dmitri_Zagidulin: And go ahead. Dave Longley:
Dave Longley: …
Dmitri_Zagidulin: Yeah. No,… Dave Longley:
Dave Longley: I didn't mean to interrupt. my driving force for having these things be of the same type is I'm expecting a digital wallet to want to filter the list of render methods based on…
Dmitri_Zagidulin: please go ahead. Dave Longley:
Dave Longley: what it supports. And I think it would be rather awkward to say, I support these three different types and…
Dmitri_Zagidulin: Beautiful. Dave Longley:
Dave Longley: my filter's going to go look in for something that approximates access mode for all three of them which might look slightly different for this particular use case I would rather have the wallet say I understand suite render methods and I'm going to look for and they all have access mode in the same place the situation that the user's in the workflow that they're in is a tap situation or it's a audio or video situation and I'm going to filter out the render methods knowing that they all share that property and…
Dave Longley: work that way. So, I'm looking for properties that the digital wallet's going to use to filter things first and then the digital wallet will go ahead and express the will actually do the rendering based on…
Dmitri_Zagidulin: I'll wait.
Dave Longley: what the render suite says. And that all seems unified to me. If we're going to have three different classes or many different classes that all have different modeling, I don't think you can get that same sort of simple experience when you're implementing a digital wallet.
Dmitri_Zagidulin: Agreed, Benjamin.
Benjamin_Young: Yeah, I think it'd be useful we're kind of implementing rather than knowing…
Benjamin_Young: where and why we're implementing to write up the wallet wants to XYZ And what does it need to take its action? if the use case because we keep switching them in and out, but if the use case is the wallet needs to find the NFC,…
Benjamin_Young: the tapable credential encoding, whatever that thing is. how is it thinking and then how is it expressing that to the individual? and then what affordances does the JSON need to provide for it to know that? And that's probably not application octet stream because that's the trash bin of media types like everything everything is octed stream.
Dmitri_Zagidulin: super generic.
Dmitri_Zagidulin: Yeah, it is a tough bit.
Dmitri_Zagidulin: Okay. …
Benjamin_Young: So and it wouldn't be that in payload or anywhere else it could sus it out, it would need to be something like an access mode of tap. But then, 300 years from now when we're no longer using NFC and we're using, forehead to forehead, then what is that? how do we express that? It's probably not.
Dmitri_Zagidulin: that would be access mode bonk, right? Forehead to forehead.
Benjamin_Young: Yeah, B for sure.
Dmitri_Zagidulin: That'll be great.
Benjamin_Young: Bon, but the protocol probably also changed.
Dmitri_Zagidulin: Yeah. Yeah. Yeah. You're right.
Benjamin_Young: And…
Dmitri_Zagidulin: Yeah. Yeah. Yep.
Benjamin_Young: NFC is a known thing right now but what is it simil similar to Bluetooth affordance or something like that it kind of matters but it kind of doesn't because you want to just hand over this this is a data description so you want to tell the wallet hey I've got this stuff and…
Benjamin_Young: here's this is why I'm providing this stuff and then the wallet or the render is the thing that determines protocol and determine needs to know enough about the stuff you're handing it to know which pipe to push it down. …
Dmitri_Zagidulin: got it.
Benjamin_Young: it may just be an unfortunate fact that NFC doesn't have its own media type.
Dmitri_Zagidulin: Okay. Right.
Benjamin_Young: I don't know.
Dmitri_Zagidulin: And for all we know, it does I don't actually Okay. All right. So, let's step back and make sure we don't lose this. This is great. we've got several open questions and we have consensus on one. we'd at least use these three method categories.
Dmitri_Zagidulin: static list and detail whatever whichever names we give them. we definitely need an static method. Open questions how are we dispatching off of type or render suite? it would be great.
Dmitri_Zagidulin: It would be great if I picked one. Okay, so that's one thing to pick. the second open question is how are we nesting the fields? keeping in mind that we want the three categories to Go ahead on the queue. Nope. Nope.
Dave Longley: I didn't want to interrupt your flow, but I was going to take issue with it would be great…
Dmitri_Zagidulin: Not at all. Go ahead.
Dave Longley: if we switch off maybe I mean type you're totally switching what you're working with. And if each of these does similar things, switching off of type, I don't know if that's the right thing to do. it feels like too much of a hammer or I don't know buzz saw when you want to scaple. I don't know what the right analogy here is. but each of these seems like they at least share some base class that has this sort of access mode thing as part of it there's something in common What?
Dave Longley: these that would allow you to be looking at them together in a group as opposed to individually just based on their type. it type feels like it's at the wrong level of resolution to make the kinds of decisions you need to make.
Dmitri_Zagidulin: Ivon.
Ivan_Herman: Let me remind you that the current vocabulary already has a type called render method with capital R.
Ivan_Herman: Which I think it's a vocabulary from day one or has been. So we are talking about possible subtypes of render method but we have that already and we cannot remove this now and…
Dave Longley: That is true.
Ivan_Herman: let me check whether it's true let me check whether it's true or that was my daydream let Hey, heat.
Dave Longley: Sure, you can go ahead and check that. But we have had this conversation before where we didn't want to add anything to the root render method…
Dmitri_Zagidulin: Dr. I have Von and Benjamin.
Dave Longley: because there might be other decisions for other types of render methods that people might come up with in the future and future versions of the spec that would not do for example maybe this access mode thing. Maybe they'll do something else. And we're looking for a category that's going to cover what we know we want to do now without making it so that no one could do anything else who more clever people than ourselves might come in later and come up with a better render method sub super class or it's a subclass of render method but it's an intermediate class that covers whatever it is they want to do and as a digital wallet I would want to potentially support both of those, but they're going to behave in different ways.
Ivan_Herman: Yeah. So we have a reserved class…
Ivan_Herman: which is called render method whose definition is pretty much empty. It's the object of a with non- capital render method property that's all that class we have and if we have that then let's fill it with some sensible thing that we feel are common as we have it as we have it and…
Dmitri_Zagidulin: Wait.
Dmitri_Zagidulin: Say that again just to make sure I heard you right. We have reserve class. Got it.
Ivan_Herman: we have some properties that we think are common to all render method then by all means you we have to define it with that class.
Dmitri_Zagidulin: Got it. Okay. Understood. So, we've got a class. We can put common properties in there. That's good. It's still an open question on whether we want to switch off of type or Ivan Herman:
Ivan_Herman: Their open question is whether we create subasses for render method or we rely exclusively on some term within it. I think that's the way you're saying it.
Dmitri_Zagidulin: I think there's a third option I think that Dave is bringing up that neither subclass wait is that correct what said Dave does…
Dmitri_Zagidulin: what you're proposing fit into those two options? Okay.
Dave Longley: No.
Dave Longley: So, I'll just quickly say I'm concerned we'll lose our placeholder for future proofing if we start putting the things that we think are common to all render methods on the render method class. we might get that wrong. I'd like to keep that thing as empty as possible and make another thing and then we can decide if that other thing is all we need or if that other thing should be itself an abstract class that we extend
Benjamin_Young: So, I think the last time we attempted this, it was something similar of leave the foot in the door for all the future things. and what we ended up doing was coming up with super weird render method renderers and bad class names because we weren't sharing anything in the super class of any kind. So it feels Dave like you're suggesting we have a capital T thing definition that is render method that essentially nobody should ever touch or define anything on and then we have other things downstream.
Dave Longley: That's right…
Benjamin_Young: Right. Right.
Dave Longley: because that is the range of the render method property.
Benjamin_Young: But it's already led to weird things like using template render method on non-mplated things. And we're back to Yeah,…
Dave Longley: No, I think those things are decoupled. if we just left render method alone and we invented render method then if you want to use a type system you can make a static render method you can make a templated render method and…
Dave Longley: those all ex extend from fu but you didn't stomp on remove the possibility for future other things that inherit from the totally empty render method.
Dmitri_Zagidulin: What the hell?
Benjamin_Young: I think I'd like to see how the modeling shakes out this time because last time it didn't seem like an improvement. but I understand now what you're trying to do with leaving it just a platonic notion of a render method with no actual meaning. But yeah,…
Dmitri_Zagidulin: What would you…
Benjamin_Young: I'm curious what all the class names are going to shake out to Go ahead, Demetri.
Dmitri_Zagidulin: what would you call to it's not like render method seems generic like this is the capital T thing like Benjamin said parent of all the classes you're proposing something as generic
Dmitri_Zagidulin: But also in between …
Dave Longley: Here's a terrible name,…
Dmitri_Zagidulin: what would you call it?
Dave Longley: Render method and it has a render suite on it and it has an output preference or an access mode or accessible render method and it has an access mode and then everything extends from that. There's any number of names we could give this thing and those names are going to depend on what we decide are which properties are in common with the three types of renderers this group has just for today in 2026 said this is what we think we need and they're going to have these things in common.
Dave Longley: We don't know if we're going to make a mistake when we do that. And so let's not close the door on all other possible render methods or making or…
Dave Longley: or create a weird vocabulary problem where the range of the render method property is no longer just render method. It's other things. So there's some combinatorial list.
Dmitri_Zagidulin: Understood.
Dmitri_Zagidulin: So you're proposing something like this for the moment.
Dave Longley: I'm just saying let's not mess with the root render method and…
Dmitri_Zagidulin: Got it.
Dave Longley: either we're going to have something like that. We might end up with just What's on line 62 sweet render method and…
Dmitri_Zagidulin: Okay. Uh-huh. Dave Longley:
Dave Longley: it covers everything somehow. Or maybe we do need subtypes and…
Dmitri_Zagidulin: Uh-huh. Got it.
Dave Longley: those are what you have listed.
Dmitri_Zagidulin: Got it. Go ahead. You Yeah.
Ivan_Herman: So that's obviously something that we can decide later when we have at least those three properly specified that we are converging to as possibilities. That being said,…
Dmitri_Zagidulin: Yeah. Back.
Future Discussion Topics
Ivan_Herman: I already see the render property appearing everywhere, which for me looks like a property that is relevant to all render methods for obvious cases. So for example, the render property for me would be a candidate to put into the render method as a kind of a generic property because we have it everywhere. For all the others probably we can leave them for the time being.
Ivan_Herman: But again we can see that when we define all three others in a proper way
Dmitri_Zagidulin: I think right agreed and I think Dave is arguing for let's not put render property into top level render method let's give ourselves future room for mistakes and nest it at least one level. So that's something to discuss. But I agree with you that okay so overall overall shape is clear. We need to decide whether we need subasses or not. we've agreed that we need these three categories. So now I think the work that remains to be done is to figure out what to name these three categories and to figure which fields
Dmitri_Zagidulin: go into each one of them and can we extract some fields in common at least one level higher? So, with an eye towards the time, we've got nine minutes left to the top of the hour. What are some good concrete next steps? It sounds like we should So, earlier on, we had two sort of different proposals.
Dmitri_Zagidulin: We had the template render method sort of as is right now and I was proposing that we have static render method but it sounds like the conversation has evolved a little bit since. go ahead. Who was that?
Kayode_Ezike: Sorry, that was me. I was going to type it, but I was going to say we should probably create issue so that we can discuss this asynchronously between now and next call. That's the main thing I was just going to propose.
Dmitri_Zagidulin: So let's create shoes. and those issues would be what one is let's see superclass approach do we put fields in common into the top level render method or nest
Dmitri_Zagidulin: it one lower as something like sweet render method. So that would be issue two would be and please feel free to interrupt or jump in somebody since time is short. How do we dispatch off of subtype or subtype So we got two options essentially subset is always rendered and we're just dispatching off of weap issue two. What else?
Kayode_Ezike: Let me just jump in, I guess. maybe just like a naming issue to solidify all the names for the three different types that we're trying to get to.
Dmitri_Zagidulin: got a solidify name for the render method categories static list view detail view…
Ivan_Herman: Wasn't it data view rather than this view?
Dmitri_Zagidulin: which are temporary code names for them. All right. Fantastic.
Dmitri_Zagidulin: Baby…
Dave Longley: Yeah, list is a little too specific. It's some kind of view on fields…
Dmitri_Zagidulin: if you data view and…
Dave Longley: because it could be, cards, lists, whatever.
Dmitri_Zagidulin: then okay so by that logic what would you call the third category? Got it.
Ivan_Herman: I think we have HTML view…
Ivan_Herman: which sort of covers it at least in my view.
Dmitri_Zagidulin: Got it. Okay. Understood. Yep.
Dmitri_Zagidulin: Go ahead.
Kayode_Ezike: Or maybe …
Kayode_Ezike: if we're using detail maybe we should use item instead of data just to make that parallel too. Anyways, this probably can be discussed in the issue too. So it's not
Dmitri_Zagidulin: I mean this is the naming discussion, these are very temporary code names just so that we can open the issue. Okay.
Dmitri_Zagidulin: Do I have any volunteers to open at least one of these issues?
Kayode_Ezike: Yeah, I can take one.
Dmitri_Zagidulin: Which one would you like?
Kayode_Ezike: I'll take the last one.
Dmitri_Zagidulin: Last one. Okay. Dave, do you want to take this middle one? since you seem to have stronger feelings about Okay.
Dave Longley: Sure.
Dmitri_Zagidulin: Dave and super class approach. I can open this one. All Simon the top of the hour. We want to go a little early to give ourselves time to get to the next call. anything else we're missing? I'm really appreciative of the conversation. Looks like we're making decent progress.
Dmitri_Zagidulin: we can at least nail down the static method fairly soon. it sounds like I think overall we've got decent consensus on the data item the JSON card thing and then we can argue about the HTML view based on the red modeling etc.
Kayode_Ezike: Yeah. Could you just share that link that you were using for the notes?
Dmitri_Zagidulin: Last minute questions reminders from the group.
Dmitri_Zagidulin: Yes, absolutely. the thing is I mean I'm reluctant…
Ivan_Herman: Yeah, that was a general thing.
Ivan_Herman: I mean, I think one other possibility is that you somehow copy the whole thing into the Okay, that's one possibility.
Dmitri_Zagidulin: because these are fairly messy, but I wanted to have this scratch notepad. Ivan Herman:
Ivan_Herman: Yeah, I understand that. On the other hand,…
Ivan_Herman: I am certain not responsible, but I am caring about the minutes and…
Dmitri_Zagidulin: I appreciate that.
Ivan_Herman: this information and my own experience reading the minutes generated by the tool here on other task forces is not very good. And this is…
Dmitri_Zagidulin: I appreciate that. Okay. So,…
Ivan_Herman: but okay…
Dmitri_Zagidulin: let's start with this. Ivan Herman:
Ivan_Herman: if you have the pointer there That should be okay. Bye-bye.
Dmitri_Zagidulin: Yeah. Yeah. Yeah. Okay. Thank you so much everyone. great conversation, good progress. I'll talk to you all in a couple weeks. Cheers. Meeting ended after 00:57:23 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.