Requirements: Add `Criterion.relatedLots`

[duncandewhurst]

Draft data from Belarus includes a boolean tender/lots/forSmallScaleBusiness field to indicate when a lot is only open to SMEs.

Assuming this can be considered a qualification requirement, there are two possible approaches to modelling this, both of which involve changes to extensions:

Option 1 - Add a field to the lot object

Follow the approach used in the draft data and add a field to the lot object. Suggest renaming field to smeOnly to reflect the use of the field to indicate that only SMEs may bid, rather than the semantics of forSmallScaleBusiness which could be interpreted as meaning that the opportunity is suitable for SMEs (UK data includes a field for this purpose).

Pros: Simple modelling Cons: Only applicable to tenders which use lots

Option 2 - Use the requirements extension and add a relatedLots field

{
  "tender": {
    "criteria": [
      {
        "id": "0001",
        "title": "Bidders for the specified lots must be SMEs",
        "relatesTo": "tenderer",
        "relatedLots": ["1"],
        "requirementGroups": [
          {
            "id": "0001-001",
            "description": "Bidder is an SME",
            "requirements": [
              {
                "id": "0001-001-01",
                "title": "Bidder is an SME",
                "dataType": "boolean",
                "expectedValue": true
              }
            ]
          }
        ]
      }
    ]
  }
}

Note: This PR is required to make the above data valid, due to "boolean" being omitted from the permitted types for expectedValue.

Pros: Applicable to tenders which include this requirement but don't use lots Cons: Complex modelling

[duncandewhurst]

@jpmckinney interested in your views here, my sense is that use of the requirements extension for this purpose seems unnecessarily complex since it would involve a user flattening three additional arrays to determine if a lot was only open to SMEs

[jpmckinney]

We want to balance complexity and standardization (i.e. having only one way to express the same thing). In terms of standardization: For procedures that are not divided into lots, we would presumably use the requirements extension; we should therefore use the same extension when the procedure is divided into lots. The problem with Option 1 is that it lowers complexity by weakening standardization. So, I favor Option 2.

In general, a consequence of a high degree of standardization is that specialized tools are needed to unravel the resulting complexity – because there's only so much that can be done to limit complexity while preserving standardization.

[duncandewhurst]

I've renamed the issue to reflect the outcome of the discussion.

[jpmckinney]

Closed by https://github.com/open-contracting-extensions/ocds_requirements_extension/pull/33