Problem
From @dlindhol
- Given: The info stopDate is the "date/time of the last record of data in the entire dataset" (with an exception for active datasets)
- Given: The data request stop time parameter is exclusive
- Given: A request for a stop time after the stopDate is an error (1405)
- Conclusion: I can't get the last time sample of an inactive dataset.
Options
-
Add "unless stop=stopDate in /info response" to "The data request stop time parameter is exclusive" where stopDate is literally the string stopDate.
- Servers that don't support it would return 1405. This would be confusing if user is used to working with server that supports.
-
Add "unless stop=9999-01-01 in /info response" to "The data request stop.
- Servers that don't support it would return 1405. This would be confusing if user is used to working with server that supports.
-
Add "unless stop=stopDate in /info response" to "The data request stop time parameter is exclusive" where stopDate is the value ofstopDate.
- The URL would get an additional time sample if the server is upgraded to support this behavior.
-
Add keyword (and mention in capabilities); does not break existing behavior
include_stop={true,false} is more verby, consistent with include=header Best option
stop_inclusive={true,false}
stop_is_inclusive={true,false}; ugly name
inclusive=stop; Odd because "stop" is the only option. Does this apply to any stop or only when stop=stopDate.
Conclusion
Adding a keyword seems to be the best option.
Could allow no stop parameter => use inclusive stopDate in info. Then no new keyword needed.
Revisit recommendation of stopDate padding for active datasets and give reason that we want URLs to always return the same content to enable reproducibility^$.
^$ even though data providers don't always support; perhaps add capability of persistentURLs (won't change dataset and parameter names; may add parameters) and constantURLs (response won't change ever).
Problem
From @dlindhol
Options
Add "unless stop=stopDate in /info response" to "The data request stop time parameter is exclusive" where
stopDateis literally the stringstopDate.Add "unless stop=9999-01-01 in /info response" to "The data request stop.
Add "unless stop=stopDate in /info response" to "The data request stop time parameter is exclusive" where
stopDateis the value ofstopDate.Add keyword (and mention in capabilities); does not break existing behavior
include_stop={true,false}is more verby, consistent withinclude=headerBest optionstop_inclusive={true,false}stop_is_inclusive={true,false}; ugly nameinclusive=stop; Odd because "stop" is the only option. Does this apply to any stop or only when stop=stopDate.Conclusion
Adding a keyword seems to be the best option.
Could allow no
stopparameter => use inclusivestopDatein info. Then no new keyword needed.Revisit recommendation of stopDate padding for active datasets and give reason that we want URLs to always return the same content to enable reproducibility^$.
^$ even though data providers don't always support; perhaps add capability of
persistentURLs(won't change dataset and parameter names; may add parameters) andconstantURLs(response won't change ever).