Proposal: JSON Schema Rendering Objects (JROs)

[andorsk]

I'd like to talk about this during the next DIF call as a STRAWMAN proposal, of a specification I'm calling JSON Schema Rendering Objects (which I call JROs)

The concept here is to provide a standard way to describe objects requiring to be consistently rendered across multiple devices with a customizable definition. In a lot of ways, it's trying to generalize and extend CM and WR to a single abstraction. It may help addresses the lack of customization and extensibility the current specs have.

Heavily inspired by JSONForms, it has 4 properties:

• data property: which specifies the data to be rendered
• schema property: which specifies the schema that the data should conform to
• layout property: specifies the suggested layout for render
• styles: which specify styling hints for how to render the object

Credentials would be one implementation of a JROs, of possibly many others.

Another point would be that many predefined objects could be defined, like avatars, images, thumbnails, etc, and specified as "standard objects".

I'd like to discuss this at the next WR call and see if there's any viability in exploring this concept further.

Here's the STRAWMAN:

{
    "data": {
         "thumbnail": {
            "uri": "https://dol.wa.com/logo.png",
            "alt": "Washington State Seal"
          },
          "hero": {
            "uri": "https://dol.wa.com/people-working.png",
            "alt": "People working on serious things"
          }
    },
    "layout": {
      "type": "HorizontalLayout",
      "elements": [
        {
          "type": "Control",
          "label": "Thumbnail",
          "scope": "#/properties/thumbnail"
        },
        {
          "type": "Control",
          "label": "Hero Image",
          "scope": "#/properties/hero"
        }
      ]
    },
    "styles": {
        "background": {
            "color": "#ff0000"
        },
        "text": {
            "color": "#d4d400"
        }
    },
    "schema": {
      "$schema": "http://json-schema.org/draft-07/schema#",
      "title": "Entity Styles",
      "type": "object",
      "definitions": {
        "image": {
          "type": "object",
          "properties": {
            "uri": {
              "type": "string",
              "format": "uri"
            },
            "alt": {
              "type": "string"
            }
          },
          "required": ["uri", "alt"]
        },
        "color": {
      "type": "object",
      "properties": {
        "color": {
          "type": "string",
          "pattern": "^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$"
        }
      },
      "required": ["color"]
        }
      },
      "properties": {
        "thumbnail": {
          "$ref": "#/definitions/image"
        },
        "hero": {
          "$ref": "#/definitions/image"
        },
        "background": {
          "$ref": "#/definitions/color"
        },
        "text": {
          "$ref": "#/definitions/color"
        }
      }  
    }
    
}    

[andorsk]

Some notes from DIF slack convo:

• JSON Schema is reasonable to describe this stuff
• Some issuers would like to control the image of the vcs in the wallet. That is not easy for us as we try to keep a design style
• Some required and optional property in styling hints.

Sample:

[decentralgabe]

The thing i'd ask is are there any other graphic descriptor languages (like css perhaps?) that are better suited to the task than CSS.

I am imaging that the wallet rendering spec will generically apply to objects that themselves have their own schemas/json - so having more json schemas could be confusing..worth discussing

[andorsk]

@decentralgabe is the scope just limited to styling ( as css is focused on )?

There's also a conception of a "data model" in WR that css doesn't provide I think is required no? happy to discuss this over the call. Definitely STRAWMAN, so we can work about the viability of the concept. Less concerned with the specifics right now and more the general approach.

[decentralgabe]

Let's discuss in call

[andorsk]

Discussion last week was this was reasonable to propose, but need more alignment and discussion to move forward. See notes from https://github.com/decentralized-identity/presentation-exchange/blob/main/agenda2023-1.md#january-19-2023 for more details.

[kimdhamilton]

@csuwildcat @decentralgabe Any thoughts on this proposal?