-
Notifications
You must be signed in to change notification settings - Fork 7
Normalization of keywords #77
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
Comments
Action items: Clarify the changes and list them out |
Here's a breakdown of the current status of potentially confusing keywords, followed by proposed changes. catalogrequest: no parameters
inforequest: parameter is "id" of dataset
datarequest: parameter is "id" of dataset with "time.min" and "time.max"; can also request just some parameters with the "parameters" keyword in the request URL Proposed ChangesThe proposal is to change the
to this
Also, the |
There was brief discussion on today's telecon about this. Everyone agrees on these:
Less clear are what to do about the People can comment here about what they think is best for HAPI, and we will have a dedicated meeting later this week to resolve it. |
I think we should lean as much as possible to using the same terminology as SPASE: ProductKey for catalog ID/dataset name, ParameterKey for parameter name, ResourceName for catalog/dataset title. The idea is to have a common description of a dataset that can be used for all purposes. We should be able to run a HAPI server solely off the info in the SPASE descriptions. [For this reason, we should also add the URI Template scheme that we created to SPASE as a field.] |
I think we should split this discussion into two parts: (1) Internal normalization (The point of the original issue) Before we try (2), I think we need to come to an agreement on (1). Item (2) is a more difficult discussion and I think it is better to do one thing at a time. I recall that very early on we decided to use just "id" and not parameterKey, etc. and I think we should find our notes about this decision before attempting to undo it. |
The important part about item 2 (normalization to SPASE) is that there is a one-to-one mapping. SPASE and HAPI have different purposes, and we have to weigh two conflicting pressures: a) have HAPI make sense on its own and be internally consistent; b) have HAPI integrate easily with SPASE
|
Because this turned into two separate issues, and the first is resolved, we are going to close the ticket for that aspect, and leave the second one unresolved. If anyone wants to suggest changes to bring keywords more fully aligned with SPASE, that could be a separate ticket, and this would likely require a lot of discussion. We have agreed to change the request interface from this: And similarly for the info request (change The older usage is still supported in the new spec version (3.0), but is deprecated. We will need to add / modify the error responses to warn about use of deprecated elements. The spec still needs to be modified to reflect this significant change. |
Should |
Summary of general agreement
No
In the documentation, warn that in 4.0, only Continues to be raised periodically:
This was decided upon early on. I suggest it should be proposed in another issue if there is more interest in it beyond discussing it on a telecon. Ideally, the issue description would include a discussion of what the decision was and why the decision is wrong. |
In dataset, we should use
id
instead ofname
. Same for `bins'.URLs should be
dataset=ID¶meters=IDs
instead ofid=ID¶meters=IDs
.time.min
andtime.max
should be replaced withstart
andstop
.In catalog response, consider allowing the use of
description
with the note that this description should match that in the info response for that dataset. Possibly removetitle
from the catalog response as it is inconsistent.May want to also allow catalog response to include additional information about a dataset, for example, startDate and endDate and cadence (in the case where info responses are large, clients may want the ability to get this information more quickly).
The text was updated successfully, but these errors were encountered: