Open swcurran opened 2 years ago
On another note. I think the spec. is not detailed enough in this and should be far more precise about what exactly can be done. I was looking at the spec here: https://oca.colossi.network/v1.1.0-rc.html
What exactly would you like to add there additionally? What would be the reasoning behind it?
Somewhat depends on the answer to my question #4 , we might have the need declarative data about the credential itself, vs. about the attributes of the credential (or should I say data elements of the data structure).
I guess since the spec. says there can be more elements, I was wondering how to do that.
Also would like it clear that we don't have to repeat the same "name" and "description" values on all the lines of the Excel. I was testing out what happens if I put different things on the lines. I assume only the first value is picked up.
I see no problem adding additional descriptive or contextual attributes about the underlying Capture Base in the Meta Overlay. I'm intrigued to know what you have in mind.
The background story of that particular overlay type is that when we were rendering a form in our parser, we got to a stage where we could translate the entire form into a different language, except the original form title and description, which would remain in English. So we fixed that issue by moving those two attributes into a new overlay type - the "Meta Overlay".
Here is something to think about for the future development of OCA. The transient objects in each of the four data domains are:
Although the underlying Capture Base would be stable, the presentation of those transient objects will differ. In this case, you should be able to create four different Meta Overlays for the objectual rendering of those transient objects in a specific language (e.g., English).
If we were to add a "transient_object_type" attribute into the "Meta Overlay", we could then specify the transient object to which it corresponds. Just a thought.
We have only been working with "Forms" and "Credentials" until now. However, I envisage the inclusion of "Notices" and "Contracts" in the future. Worth bearing that in mind as we develop OCA.
The tricky part is do we open things up to an OCA Publisher adding any name/value pair they want (thus creating being reliant on publishers and consumers to agree on the ones to use) or do we allow only specification defined names? I think the specification needs to define an answer to that.
I agree.
If we decide to add a "transient_object_type" meta attribute into the core overlay types, my preference would be to restrict the defined names in the specification. For the first version of the spec, I would go with:
"transient_object_type" = "form" or "credential"
I don't think we need to add "notice" and "contract" at this stage. We can add those later as those use cases come to the fore.
Perhaps "document_type" is a better name for that suggested meta-attribute.
e.g., ...
{ "capture_base" : "EPMaG1h2hVxKCZ5_3KoNNwgAyd4Eq8zrxK3xgaaRsz2M", "object_type" : "spec/overlay/meta/1.0", "document_type" : "credential", "language" : "en", "name" : "Digital Passport", "description" : "An official travel document issued by a government." }
We could also put that meta-attribute into some of the other core overlay types (e.g., Label overlay, Information overlay, etc.).
In the Spec, the Meta overlay is defined as:
In the Excel to OCA Bundle converter, it appears that only Name and Description can be defined, and only one value is picked up.
Questions: