META: Missing fields in schema #40
Comments
jpmckinney
changed the title
|
@timgdavies How should we proceed to fill in these fields (not urgent, just in terms of process)? Or should a field |
|
These should be required. Some of these are part of core extensions, so would need to be updated as part of a bug-fix release. Others we can just update ad-hoc, so I'm putting this on ToDo list for schema work next week. |
|
Location and lots are core extensions, so I'll work on those now as part of 1.1.3 prep:
|
|
I've added descriptions for location and lots extensions. This did surface one issue in the lots extension, where /definitions/Tender/properties/lotDetails/ uses a $ref just for layout of the components of the lot (rather than in the case where there is an array, and then objects in that array). This means the addition descriptions added (for which I duplicated the descriptions from the target) are redundant. It is possible we should refactor the lots extension to remove this reference, unless there are likely to be cases where LotDetails are re-used by some other extension. This should inform our guidance about how to structure extensions, and when to use $ref |
|
If we don't presently anticipate reuse of LotDetails, then we should avoid the |
|
Noting that once this issue is closed, I can uncomment a test. |
|
@timgdavies ocds_participationFee_extension is also a core extension. Could you add its three missing title/description properties? (see issue description) |
jpmckinney
added
Community
|
Removing 1.1.3 milestone, as all core extensions now fixed. |
|
Do we want to fix this as part of PPPs cleanup? @duncandewhurst |
|
I've added the missing fields for all the PPP extensions, in one instance (budget and projects extension) I noted the same issue with use of $ref as Tim mentioned above so amended the schema accordingly. I also noticed we aren't consistent with whether we include the parent object name in the title of fields. The style guide says we shouldn't do that in names of properties and objects but doesn't specify an approach for field titles. I've used whatever seemed most appropriate, but think that in general we probably should include parent object names in titles, since some users will work with the flattened schema without seeing the full field path. |
|
I think that may indicate an opportunity to improve the flattened schema (e.g. add a column with the name of the containing object), rather than make all field titles more verbose. There are use cases for which verbosity is undesirable (e.g. the automatic generation of a vertical form will repeat the object name, making tasks like finding the desired field slower, because in general any offset of the target word from the start of the line causes slower task times in user tests). |
|
I have a commit for API extension. This is done now. |
Blocking open-contracting/standard-maintenance-scripts#27
50 fields missing in 9 extensions.
Core
ocds_participationFee_extension/release-schema.json
ocds_location_extension/release-schema.json
ocds_lots_extension/release-schema.json
Community
PPPs
ocds_budget_projects_extension/release-schema.json
ocds_finance_extension/release-schema.json
ocds_metrics_extension/release-schema.json
ocds_performance_failures/release-schema.json
ocds_requirements_extension/release-schema.json
Other
api_extension/release-schema.json
ocds_budget_breakdown_extension/release-schema.json
The text was updated successfully, but these errors were encountered: