Open swcurran opened 2 years ago
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.
Please see https://github.com/THCLab/oca-ecosystem/issues/10 .
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:
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