Casper Welzel Andersen
Casper Welzel Andersen
> If we use this e.g. for validation in the REST API, do we want to allow all possible formats? Maybe not publicly? However, it also seems unintuitive that a...
As the references' properties/fields are currently BibTeX one-to-one (see [description of the `references` endpoint and entry type](https://github.com/Materials-Consortia/OPTIMADE/blob/develop/optimade.rst#references-entries)), this will introduce a shift away from that. I am fine with refining...
> > As the references' properties/fields are currently BibTeX one-to-one (see [description of the `references` endpoint and entry type](https://github.com/Materials-Consortia/OPTIMADE/blob/develop/optimade.rst#references-entries)), this will introduce a shift away from that. > > This...
I'll try my best to explain, but I'm sure it's going to get convoluted. First, concerning the three categories for the Entry list specific properties: >- Properties marked as REQUIRED...
>- OPTIONAL: property is MAY have non-`null` values. Could just as well be `property MAY have `null` value(s)`, right? > Or am I missing something? Putting it down this way...
> This issue has been marked with the v1.0.0 milestone. My personal interpretation is that this is NOT release-blocking and can be moved to the v1.1 milestone, because it is...
The latter part raised here, is exactly a use case of mine. For the MarketPlace project we intend to implement OPTIMADE as a supported way of connecting a database to...
> What problem/use case would we address with further standardizing authentication? I can't come up with one. And I am happy about this answer. It was merely a documented answer...
> I would personally prefer to stick to the JSON API types, just so we don't mix standards in the spec. Are the OpenAPI types a superset of JSON types,...
> We essentially have type data defined for each entry type in section 7 under 'Type'. It is just a question how we "typograhpically" should represent things like 'list of...