Proposal: New format Excel spreadsheet as input to the bundle creation process

[swcurran]

As we in the Hyperledger Aries project look at how we can apply OCA to solve our rendering issues, we'd like to look at some adjustments to the OCA Source Excel file being used. We really like the idea of managing the OCA source data in Excel, as it is very easy for our contributors/translators to use, but we'd like to propose a couple of adjustments.

As a first draft, I've revised our instance of an OCA Excel file we already use, to show the changes I think we'd like to have. I welcome input from others on what else we should include. The goal is to not make this Aries specific, but to include features that we think any OCA producer/consumer would likely use.

Our schema, current format Our schema, proposed format

The changes:

• Language tabs:
  • Change the Meta Overlay columns (A and B) to be a name/value pair for generating the Meta overlay.
  • The first two rows MUST be "name" and "description", but the additional rows can be name/value pairs.
    • Our intention is that in the "OCA for Aries" RFC/spec. we will define a set of names that are expected in an OCA Bundle in the Aries ecosystem.
• New "Template" tab:
  • A list of name/value pairs in columns A and B that will be used to generate the "template" overlay, which is an alternative to the Credential Layout overlay for rendering the data.
  • There are no required names that must be included.
    • Our intention is that in the "OCA for Aries" RFC/spec. we will define a set of names and data formats that are expected in an OCA Bundle in the Aries ecosystem.
• Main tab:
  • Added in Cell 3B a setting for the output format of the conversion, with options "Output Format: JSON" and "Output Format: ZIP"
  • This allows the Excel file to be self-describing vs. relying on a runtime parameter to produce the expected output.

In parallel to the "template" overlay -- we need to define the template overlay to be either part of the OCA Spec, or an extension to the spec.

I welcome feedback and discussion on this. What is not appropriate? What is missing? Are there better ways to achieve the same result?

@foxbike @jcdrouin21 @cvarjao @blelump

[blelump]

Hey Stephen,

thanks for your feedback. First two points make sense, but need to be further elaborated as this is the discussion about the overall presentation layer approach (I'll start another issue as it doesn't fit here).

The last proposal introduces implementation specific behavior into implementation agnostic XLS OCA template. In other words the XLS that defines the OCA is purely a template. How the client is willing to represent it internally, that's up to the client. In the end whether this is YML/JSON/ZIP or any other format, even not officially supported, is up to the client and therefore use case specific.

[blelump]

Please see https://github.com/THCLab/oca-ecosystem/issues/10 .