Mustache Template Rendering Algorithm

[Echsecutor]

The current section about the rendering algorithm

https://w3c.github.io/vc-render-method/#render-templaterendermethod

is a stub. This only describes a very small subset of mustache templates and not in a very readable way. I would suggest to refer to the official documentation instead of trying to reproduce parts, i.e.

• https://mustache.github.io/
• https://mustache.github.io/mustache.5.html

[Echsecutor]

To give some context: We have an actual use case where the credentialSubject contains an array of objects which we would like to render. This works perfectly fine with mustache templates but is way beyond the simple variable replacement algorithm in the current spec draft.

See here for an example

[Echsecutor]

The current version of the spec is lacking actual template examples. Those should definitely be added.

I just realized that the current version would use something like {{/credentialSubject/id}}, if I interpret the algorithm text section and referenz to JSON pointers correctly. Proper mustache syntax for the same variable would be {{credentialSubject.id}}. And, even worse, {{/ is an end of block marker in mustache, hence there is a conflict between the current algorithm section and using proper mustache templates.

Maybe this needs more discussion than I thought.

[msporny]

Maybe this needs more discussion than I thought.

Yes, it probably does. :)

There is also an upcoming PR, hopefully by the end of the week, that will introduce a different mechanism that removes the templating mechanism entirely and allows one to pick any templating language that they prefer. The plan is to use a strongly sandboxed HTML+Javascript engine/iframe to perform the rendering. We believe we've found a broadly supported way to do this (HTML sandboxing) and it will work for all of our current use cases.

That is not to say we couldn't define another templating mechanism that uses Mustache, but our implementation experience to date has shown how limited the SVG-based and PDF-based approaches are, and how difficult it is to specify a minimal set of pick-your-favorite-template-language in the spec.

We already have a well defined, sandboxable rendering engine that can run on both client-side and server-side, and ships on most every platform today: HTML.

[msporny]

Based on the discussion this past week, which seemed to achieve consensus, it is unlikely that we are going to specify a templating engine but rather allow issuers to use any templating engine they wish to use via the HTML Render Method.

This is is probably going to be address via this PR: #42

I think that solution is probably going to be a better solution for you @Echsecutor, because it enables you to fully control the rendering pipeline. Please let us know if you disagree. I am going to mark this as "pending close" and will close it within a week if there are no objections.