fix: update OpenAttestationEmbeddedRenderer to EmbeddedRenderer

[isaackps]

Rename "OpenAttestationEmbeddedRenderer" to "EmbeddedRenderer".

As there is an update to OA.

---

Preview | Diff

[dlongley]

A naming question here. What about the renderer itself makes it decentralized?

From the description, it sounds like this is a renderer that uses HTML in an embedded or nested browsing context, in particular, it suggests an iframe must be used. If the latter is true (and intended to be true carrying forward), perhaps IFrameRenderer would be an appropriate name to describe why/how this renderer is different from the other renderer types.

If there's some other layer to the abstraction here and use of an iframe is an implementation detail, perhaps it suggests the name ought to be ExternalRenderer or EmbeddedRenderer -- where there is some External/Embedded "ACTION" API to communicate with it?

If the main feature of this type of renderer is that it has this "ACTION" API communication capability, perhaps the name should be based on that, e.g., ActionableRenderer or ActionDrivenRenderer (or similar). Perhaps those names are slightly awkard or insufficiently specific -- but I wouldn't suggest InteractiveRenderer since "interactivity" could be a property of many different renderer types.

[pohhendry]

Thanks for the thoughtful feedback!

After some discussion within the team, we agree that the name should stay close to how the renderer actually works. Based on your suggestions, we think EmbeddedRenderer would be the most accurate and intuitive choice, since it reflects that the rendering happens in an embedded context.

We’ll proceed with updating the naming accordingly.

[isaackps]

Hi @dlongley,

Thanks for the feedback, have updated it to be EmbeddedRenderer instead.

[msporny]

We will need to figure out the context issue in this PR.

• The PR should be updated to refer to the new issue on the topic.
• The images need descriptions for screen readers (for people that have low/no-vision sight needs). I have used LLMs to generate these descriptions and they do a pretty good job (sometimes) if you give them enough context on what the image is showing.

[dmitrizagidulin]

👍

[dmitrizagidulin]

Issue #33 (to deal with the @context and vocab issue) opened on the Weds renderMethod call. This PR can be merged meanwhile.

[iherman]

This was discussed during the vcwg meeting on 14 November 2025.

View the transcript

w3c/vc-render-method#25 and w3c/vc-render-method#30

dmitriz: those were discussed previously
… a proposal was to introduce in the core spec itself

brent: do you mean the core data model?

dmitriz: no, the render spec
… that will describe a generic render method, then we would have additional specs for specific methods
… let's look at w3c/vc-render-method#30
… the properties it introduces are general purpose (name, digest multibase, version)
… any method will need those
… So I suggest to wait on this one, as well as PR 25

brent: to clarify: this method is introducing things for a specific render method
… what you propose is to create a separate PR introducing them on the generic render method

dmitriz: correct

phila: reminds me of a discussion I had a long time ago with Mark Nottingham
… about registering a link relation type; Mark pointed out that the link relation type does not give you the media type
… a given VC may have several render method
… having an specific OCA method feels wrong

dmitriz: my understanding of the PR is that it proposes a "super class" of OCABundle

phila: that feels right

manu_: the current way the specification is structured is: we have an extension mechanism, called render method
… we are going to define the generic mechanism, and propose a few concrete ways to use it (PDF, SVG...)
… this is an enormous amount of work
… can we at least prioritize the order in which we go into these things?

manu_: I don't want us to take 2 years to get Render Methods 1.0 published

phila: difference between linking to a render method and embedding

JoeAndrieu: we want to get one, to be able to go to CR
… knowing which one is the 1st one is important

dmitriz: this is a good segway to look at PR 36, which emphasized that the spec is an extension mechanism (as manu_ and JoeAndrieu said)
… I love the idea of "let's take one"; agree with JoeAndrieu that this is going to be a difficult conversation

<dmitriz> we've implemented the HTML template, at MIT DCC. (we started with SVG, but ran into line wrapping probems, and switched to HTML)

dmitriz: SVG and HTML are widely applicable, but maybe not the ones with the most implementations

phila: as GS1, we use SVG and would like SVG to be in there
… any opinion across the room?

dmitriz: dare we bring up the dreaded word "registry"?
… We should not prioritize now, but this discussion is related to deciding what to do with those PRs.
… Let's leave 20 and 35 open for the moment.

---