+1, that’s the idea — schema by fiat at the very least. This structure should
be a flexible JSON object that can take whatever shape its attendant API would
need it to have. The goal of the “common data elements” is to provide just
enough structure to be generally useful, and it’s based on what
> On 8. Oct 2019, at 16:49, George Fletcher
> wrote:
>
> In general, it's difficult to determine how to extend for new types or if
> they should be wrapped up in "data" somehow.
>
> {
> "type":
> "https://example.com/my_field";
> ,
> "actions":[
> "read"
> ],
> "my_fi
In general, it's difficult to determine how to extend for new types or
if they should be wrapped up in "data" somehow.
|{ "type":"https://example.com/my_field";, "actions":[ "read" ],
"my_field": { "id": "" } }|
I'm assuming the above is perfectly legit and the intended way for the
spec to b
I guess we differ in our opinion of how remiss that would be. But given
what you've got in there now, the more narrow point I was trying to make
was to say that I don't think "data" is defined or explained well enough to
be helpful.
On Tue, Oct 1, 2019 at 4:33 PM Justin Richer wrote:
> I think t
I think that we need to define :some: common set to data elements in this spec,
in order to help people who are using this and trying to apply it to their APIs
do so in vaguely consistent ways. The details of which parts we standardize on
are still, I think, up for grabs. I’d be happy to have a
Hi Janak,
thanks for your feedback.
> On 22. Sep 2019, at 09:45, Janak Amarasena wrote:
>
> Hi,
>
> Since the "authorization_details" parameter is newly introduced I feel it
> would be better to show how this is used with the existing authorization
> request at the beginning of the specifi
