Many procedure data fields also apply to lots

[ColinMaudry]

A lot of BT that can describe the whole procedure can also describe individual lots. This is very much visible in the XML, where the element that describes the general information of a procedure (cac:ProcurementProject) is also a child of cac:ProcurementProjectLot that describes a lot, bringing all its own children elements.

Rough XML structure of an eForms document:

<[form type]>
     <cac:ProcurementProject>
         general information on the procedure...
     </cac:ProcurementProject>
     <cac:ProcurementProjectLot>
          <cac:ProcurementProject>
               general information on lot 1...
          </cac:ProcurementProject>
          other information on lot 1
     </cac:ProcurementProjectLot>
     <cac:ProcurementProjectLot>
          <cac:ProcurementProject>
               general information on lot 2...
          </cac:ProcurementProject>
          other information on lot 2
     </cac:ProcurementProjectLot>
     ...
</[form type]>

For example, the two possible xpaths for BT-24 (Description) and their respective mapping in OCDS:

• /*/cac:ProcurementProject/cbc:Description => tender.description
• /*/cac:ProcurementProjectLot/cac:ProcurementProject/cbc:Description => Lot.description

From a quick scan in the mapping data, BT that have an xpath that starts with/*/cac:ProcurementProject almost always have also an xpath that starts with /*/cac:ProcurementProjectLot/cac:ProcurementProject. On the other hand, many BT only have an xpath that starts with /*/cac:ProcurementProjectLot, meaning the XML schemas of eForms are rather centered on lots.

@jpmckinney What's the status of the thinking around the extension of the Lot object in OCDS? I think we're going to need it for data such as:

• description (general description of the procurement)
• procurement category (works, services, supplies) + additional
• classification (CPV, etc) + additional
• contract period
• (more examples incoming)

[jpmckinney]

Yes, in general, I am fine with adding fields from Tender to Lot.

[ColinMaudry]

I will write guidance with new fields in Lot, and when the guidance is stable we implement them.

[ColinMaudry]

There are cases, such as BT-23 Main Nature, where a BT can either be in /cac:ProcurementProjectLot (applies to the lot) or in /cac:ProcurementProject (whole procedure).

So far I write guidance with mapping to the OCDS lot as long as /cac:ProcurementProjectLot can be an ancestor. That's what I did with BT-23 Main Nature.

That's because I think it's simpler if fields that may map to a lot always map to a lot, even if there is only one.

[ColinMaudry]

On second thought, it may be strange if certain tender fields, such as tender.description, are empty in single lot situations. We could instruct implementers to mirror all applicable fields from the lot to tender in single lot situations.

[jpmckinney]

I'm fine with only data in lots. Having duplicate information can be confusing and create room for error. See also discussion in open-contracting/standard#891

[jpmckinney]

@duncandewhurst @odscjen I think your mapping work follows the pattern of putting data in the lot (even if there is only one "virtual" lot), but just want to double-check before closing this issue (e.g. maybe early on this wasn't well established yet?).

[odscjen]

@jpmckinney yes that's right, I think we agreed on that fairly early on when we were still reviewing Colin's [UNREVIEWED] mappings so I think this issue can be closed now.