Should we try to use a single type, e.g., "RenderSuiteRenderMethod", or multiple types for the known render methods of interest?

We have at least two options for modeling the three render methods ("static", "data view", "HTML") that the group seems to be coming to consensus on as outputs for this version of the spec:

1. A single type of render method that differentiates based on "suite" name.
2. Three different types of render method.

We should decide if we want to use a pattern like this:

{
  // name can be bikeshed
  "type": "RenderSuiteRenderMethod",
  // names can all be bikeshed
  "renderSuite": "static"|"data"|"html",
  // common properties to all render suites follow...
}

Or like this:

{
  // name can be bikeshed
  "type": "StaticRenderMethod",
  // a mix of common and custom properties follow
}

{
  // name can be bikeshed
  "type": "DataViewRenderMethod",
  // a mix of common and custom properties follow
}

{
  // name can be bikeshed
  "type": "HtmlRenderMethod",
  // a mix of common and custom properties follow
}

My view is that using a single type is simpler and preferable -- and we should only add extra types if they are really necessary to differentiate. Here are some reasons why:

1. If all of the properties can be modeled such that they are common, we do not need extra classes.
2. Extensions are easier (no new vocabulary terms or contexts) if the properties we come up with already sufficiently support extensibility (which might be the case if all three of these different render methods work with said properties).
3. It is simpler for a consumer (e.g., digital wallet) to filter the renderMethod set it finds on a VC based on a single supported type, with a common set of properties (with values to filter on), than to filter on different combinations of types and type-specific properties and values. Both the filtering itself is simpler and creating an API or expressing the filters is simpler. If we try to improve on this by having a common base class, we'd still need to announce it in the data itself for wallets to perform filtering (e.g., "type": ["SomeBaseClass", "HtmlRenderMethod"] vs. the simpler "type": "SomeCommonClass").

Start by reviewing the issue's two proposed render-method models and the four-comment discussion. Compare how the single type and three-type options handle the static, data view, and HTML methods, shared properties, extensions, and consumer filtering. Done means the group reaches a decision and records the selected model and naming in the specification.