-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow provider-specific data types #529
Open
merkys
wants to merge
13
commits into
Materials-Consortia:develop
Choose a base branch
from
merkys:custom-data-types
base: develop
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
05010ff
Describe custom data types in "Type handling and conversions in compa…
merkys 20cbe9f
Introducing provider-specific data types in other parts of the specif…
merkys 466a193
Require provider-specific data types to bear provider-specific prefixes.
merkys 8bd0811
Update optimade.rst
merkys 1330717
Split database-provider-specific and definition-provider-specific dat…
merkys 702bf6a
Update optimade.rst
merkys a14cc41
Merge branch 'develop' into custom-data-types
merkys 3dd56bb
Replace "database-provider-specific or definition-provider-specific" …
merkys 4869596
Update optimade.rst
merkys 1860824
Update optimade.rst
merkys 12c905d
Reorganize the other uses of string value tokens into a small list.
merkys df724fd
Put a link to the description of namespace-specific data types.
merkys 16c8273
Update optimade.rst
merkys File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change | ||||||
---|---|---|---|---|---|---|---|---|
|
@@ -220,6 +220,7 @@ representation in all contexts. They are as follows: | |||||||
A list can be empty, i.e., contain no items. | ||||||||
- **dictionary**: an associative array of **keys** and **values**, where **keys** are pre-determined strings, i.e., for the same entry property, the **keys** remain the same among different entries whereas the **values** change. | ||||||||
The **values** of a dictionary can be any basic type, list, dictionary, or unknown. | ||||||||
- Namespace-specific data type (described in `Type handling and conversions in comparisons`_). | ||||||||
|
||||||||
An entry property value that is not present in the database is **unknown**. | ||||||||
This is equivalently expressed by the statement that the value of that entry property is :val:`null`. | ||||||||
|
@@ -627,6 +628,7 @@ In the JSON response format, property types translate as follows: | |||||||
- **timestamp** uses a string representation of date and time as defined in `RFC 3339 Internet Date/Time Format <https://tools.ietf.org/html/rfc3339#section-5.6>`__. | ||||||||
- **dictionary** is represented by the JSON object type. | ||||||||
- **unknown** properties are represented by either omitting the property or by a JSON :field-val:`null` value. | ||||||||
- Namespace-specific data types use string representations. | ||||||||
|
||||||||
Every response SHOULD contain the following fields, and MUST contain at least :field:`meta`: | ||||||||
|
||||||||
|
@@ -1815,7 +1817,10 @@ The following tokens are used in the filter query component: | |||||||
|
||||||||
(Note that at the end of the string value above the four final backslashes represent the two terminal backslashes in the value, and the final double quote is a terminator, it is not escaped.) | ||||||||
|
||||||||
String value tokens are also used to represent **timestamps** in form of the `RFC 3339 Internet Date/Time Format <https://tools.ietf.org/html/rfc3339#section-5.6>`__. | ||||||||
String value tokens are also used to represent: | ||||||||
|
||||||||
- **timestamps** in form of the `RFC 3339 Internet Date/Time Format <https://tools.ietf.org/html/rfc3339#section-5.6>`__. | ||||||||
- Namespace-specific data types. | ||||||||
|
||||||||
- **Numeric values** are represented as decimal integers or in scientific notation, using the usual programming language conventions. | ||||||||
A regular expression giving the number syntax is given below as a `POSIX Extended Regular Expression (ERE) <https://en.wikipedia.org/w/index.php?title=Regular_expression&oldid=786659796#Standards>`__ or as a `Perl-Compatible Regular Expression (PCRE) <http://www.pcre.org>`__: | ||||||||
|
@@ -2070,6 +2075,10 @@ As the filter language syntax does not define a lexical token for timestamps, va | |||||||
In a comparison with a timestamp property, a string token represents a timestamp value that would result from parsing the string according to RFC 3339 Internet Date/Time Format. | ||||||||
Interpretation failures MUST be reported with error :http-error:`400 Bad Request`. | ||||||||
|
||||||||
Namespace providers MAY introduce namespace-specific data types, representing them with string lexical tokens both in filters and responses. | ||||||||
It is up to the providers to decide which comparison operators to support and how the comparisons should be performed. | ||||||||
For example, a provider that introduces a set-valued property :property:`_exmpl_set`, may decide to override the :val:`CONTAINS` operator so that :filter:`identifier CONTAINS set` is true when :val:`set` is a subset of a property. | ||||||||
|
||||||||
Optional filter features | ||||||||
~~~~~~~~~~~~~~~~~~~~~~~~ | ||||||||
|
||||||||
|
@@ -2158,7 +2167,7 @@ A Property Definition MUST be composed according to the combination of the requi | |||||||
|
||||||||
- :field:`x-optimade-type`: String. | ||||||||
Specifies the OPTIMADE data type for this level of the defined property. | ||||||||
MUST be one of :val:`"string"`, :val:`"integer"`, :val:`"float"`, :val:`"boolean"`, :val:`"timestamp"`, :val:`"list"`, or :val:`"dictionary"`. | ||||||||
MUST be one of :val:`"string"`, :val:`"integer"`, :val:`"float"`, :val:`"boolean"`, :val:`"timestamp"`, :val:`"list"`, :val:`"dictionary"` or the name of a namespace-specific data type that starts with an underscore followed by the provider-specific prefix. | ||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
|
||||||||
|
||||||||
- :field:`x-optimade-unit`: String. | ||||||||
A (compound) symbol for the physical unit in which the value of the defined property is given or one of the strings :val:`dimensionless` or :val:`inapplicable`. | ||||||||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess in the end we will want this info to go into our "standards" definitions (see https://github.com/Materials-Consortia/OPTIMADE/tree/develop/schemas#standards-definitions ). For the OPTIMADE one see here: https://schemas.optimade.org/defs/v1.2/standards/optimade.html
If forced to handle this today I would put that info into the description field there. Something along the lines of:
BUT, writing this up; even though the magnetic susceptibility tensor example is quite bogus, I realize we may be overly limiting deciding all custom datatypes must be represented as strings? Why not allow it to be expressed as any basic or container datatype?
But, back to @ml-evs comment: to allow not repeating the definition a lot, maybe this is better?:
(That reference can then be to the "standards definition" if it is included there).