Goals
- Ensure that managers (e.g., the Product Owner) can declare a prioritization order for TAP_SCHEMA "schemas" after the schema content has been defined in Felis and without editing the individual Felis files. I.e., we need to be able to override any schema_index values as part of a global decision on the order in which schemas are presented in the API and in user interfaces.
Background and strategic fit
Fundamentally it is none of any particular schema description's business to declare its priority with respect to other schemas. It doesn't know what they are, nor can it predict the future. Requiring the individual schema descriptions to be modified every time such a change is needed breaks separation of concerns.
Note that schema_index is conceptually different from table_index and column_index in that the latter two can be specified entirely internally to a single Felis file, without reference to any others, and so can be curated at a per-file level. schema_index crosses the entire ensemble of data provided through a TAP service and so has to be managed globally. (The same issue could arise witih table_index in the future if different tables in the same schema were represented by different Felis files; currently we don't do this, so it hasn't come up.)
Related subsystem issues
Database
The schema_index concept is not directly represented in the database itself, but is layered on top of the actual databases via Felis-based annotations.
Portal
FULL SUPPORT - Firefly already respects schema_index (as well as table_index and column_index)
Assumptions
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | ||||
| 2 |
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
| Question | Outcome |
|---|---|