-
Notifications
You must be signed in to change notification settings - Fork 46
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
Review Extensions conformance section #582
Comments
Possible new requirements (related to open-contracting/standard-maintenance-scripts#48):
This is to avoid an extension changing the semantics of the standard's schema and thereby breaking interoperability. If an extension desires to further document the usage of a field, it should do so through documentation, rather than through changing a field's |
Possible new requirements (related open-contracting/standard-maintenance-scripts#45):
|
I'm in favour of all of the proposed requirements. However, there is some cross-over with parts of the schema style guide, so we should consider how to keep those in sync, or whether the style guide should defer to the extensions conformance section for some points.
I think so, so that titles and descriptions for the enum values can be translated. |
Yes, once this documentation exists, we can remove some content from the style guide and link to these docs. This is quite an old issue. Some additional rules for extensions are expressed by the schema files for CSV codelists and extension.json files: https://github.com/open-contracting/standard-maintenance-scripts/tree/main/schema These tests might also go beyond the above. (The jscc documentation might be easier to read.) I'd consider this issue to be lower priority, as we have internal tools for checking extensions. For the rules to be really useful, we'd have to consider an online tool – but there are not a huge number of unregistered extensions. |
See also #1571 on rules for publishing extensions. |
Noting that |
Possible new requirements for extensions:
title
,description
andtype
, unless they are originally defined in the core schema or in another extension. Description for Value and Milestone objects #603openCodelist
istrue
,enum
must not be set.openCodelist
isfalse
,enum
must be set. META: Add enum to closed codelists ocds-extensions#32openCodelist
isfalse
andenum
is set,enum
must match the codes in thecodelist
.enum
, should we require that it be expressed as a codelist?We can offer tool support for this: both for validating extensions, and for automatically putting the codes from the codelists into the
enum
. (Both tools now exist.)http://standard.open-contracting.org/latest/en/schema/conformance_and_extensions/#extensions
The text was updated successfully, but these errors were encountered: