Their appears to be problem with the namespaces of the fields "BT-7220-Lot" and "BT-722-Contract". The fields.json shows the following:

BT-7220-Lot "efac:Funding/efbc:FundingProgramCode"
BT-722-Contract "efac:Funding/efbc:FundingProgramCode"

The actual object FundingProgramCode is not available in the efbc namespace, but appears to be available in the cbc namespace.

Hello,
not sure if this is a correct place to address this issue, but when validating through schematron CN for version 1.0.0
getting an error of BR-BT-00067-0104.

Used example.
https://github.com/OP-TED/eForms-SDK/blob/1.0.0/examples/notices/cn_24_minimal.xml

Schematron.
complete-validation.sch from
https://github.com/OP-TED/eForms-SDK/tree/1.0.0/schematrons/static

Software.
oXygen XML Editor 25.0, build 2022110706

pin-buyer_24_published.xml
cac:ContractingPartyType
cbc:PartyTypeIRCSS</cbc:PartyType>
</cac:ContractingPartyType>

ContractingPartyType/PartyType doesn't exist.

Should this be ContractingPartyType/PartyTypeCode instead?

and

pin-only_24.xml and pin-only_fin-reg.xml
cac:ProcurementProject
cac:RealizedLocation
cac:Address
cbc:DepartmentRealizedLocDept1234</cbc:Department>

Department in ProcurementProject.RealizedLocation.Address context doesn't exist in fields.json.

Should this be removed?

Comparing text messages for BT-198(xxx)-Fields in fields.json as well as in rule_en.xml-file, I realized that some error-messages named in fields.json are missing in rules_en.xml.

Is seems as if the missing messages belong to rules that have been added somehow later in the definition-process. Some of the missing rules are:
rule|text|BR-BT-00198-4292
rule|text|BR-BT-00198-4293

rule|text|BR-BT-00198-4335
rule|text|BR-BT-00198-4357

Since rules from rule|text|BR-BT-00198-1301 to rule|text|BR-BT-00198-1350 contain the same text-message as rule|text|BR-BT-00198-4292, rule|text|BR-BT-00198-4335 and rules from rule|text|BR-BT-00198-4052 to rule|text|BR-BT-00198-4101 have the same text message as rule|text|BR-BT-00198-4293, rule|text|BR-BT-00198-4357: wouldn't it be easier to define these messages only once and refer to the same message code whereever/whenever it is needed?

The English translations are currently missing for the following Schematron validation rules:

• rule|text|BR-BT-00024-0210
• rule|text|BR-BT-00024-0207
• rule|text|BR-BT-00024-0208
• rule|text|BR-BT-00024-0209
• rule|text|BR-BT-00514-0304

I've got a couple of questions regarding the usage of the repeatable properties in the various json files.

1. The repeatable property occurs in both the fields.json and the noticesubtype json files. Is it alright to assume that the repeatable properties for a specific field are the same across all these files?

2. What is the intended usage of having the repeatable propety in multiple files for the same field?

3. I came across a couple of fields which do not seem to add up. I've added an example below of one of the fields. Does the metadata in this case mean that we should only add a maximum of 1 RegulatoryDomain to PriorInformationNotice or this an actual inconsistency?

Snippet of UBL-PriorInformationNotice-2.3.xsd

<xsd:element ref="cbc:RegulatoryDomain" minOccurs="0" maxOccurs="unbounded"/>

Snippet of fields.json

{
    "id" : "BT-01-notice",
    "parentNodeId" : "ND-0",
    "name" : "Procedure Legal Basis",
    "btId" : "BT-01",
    "xpathAbsolute" : "/*/cbc:RegulatoryDomain",
    "xpathRelative" : "cbc:RegulatoryDomain",
    "type" : "internal-code",
    "legalType" : "CODE",
    "repeatable" : {
      "value" : false,
      "severity" : "ERROR"
    }
...
}

See group_nl.xml
Line 79: Feesten

The correct translation for "parties" would be "Partijen", not "Feesten" (which means "feasts"/"fests", "celebrations")

Example SVRL reports are missing some fired-rules when compared to SVRL generated through by the preview Central Validation Service,

Details

• examples/reports/can_23_contracts.svrl contains 333 fired-rules.
• Validating examples/notices/con_23_contracts.xml with the validation service produces this report, that contains 335 fired-rules.
• It seems that the additional fired-rules both apply on context /*/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/efext:EformsExtension/efac:Organizations/efac:Organization/efac:Company[(cac:PartyIdentification/cbc:ID/text() = //efac:TenderingParty/efac:Tenderer/cbc:ID/text()) or (cac:PartyIdentification/cbc:ID/text() = //efac:TenderingParty/efac:Subcontractor/cbc:ID/text())] (line 148 and 149 in the API report).

Additional information

While I haven't confirmed by generating a report with the API, here are some fired-rule contexts that I suspect are sometimes missing from the example reports.

• On contract award notices and others

  /*/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/efext:EformsExtension/efac:Organizations/efac:Organization/efac:Company[(cac:PartyIdentification/cbc:ID/text() = //  efac:TenderingParty/efac:Tenderer/cbc:ID/text()) or (cac:PartyIdentification/cbc:ID/text() = //efac:TenderingParty/efac:Subcontractor/cbc:ID/text())]
  /*/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/efext:EformsExtension/efac:NoticeResult/efac:LotTender/efac:SubcontractingTerm[efbc:TermCode/  @listName='applicability']
  /*/cac:TenderingProcess/cac:ProcessJustification[cbc:ProcessReasonCode/@listName='accelerated-procedure']
  /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingProcess/cac:FrameworkAgreement/cac:SubsequentProcessTenderRequirement[cbc:Name/text()='buyer-categories']
  /*/cac:TenderingProcess/cac:ProcessJustification[cbc:ProcessReasonCode/@listName='direct-award-justification']
  

• On contract notices

  /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingTerms/cac:CallForTendersDocumentReference[cbc:DocumentType/text()='restricted-document']
  /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingTerms/cac:CallForTendersDocumentReference[not(cbc:DocumentType/text()='restricted-document')]
  /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingTerms/cac:AllowedSubcontractTerms[cbc:SubcontractingConditionsCode/@listName='subcontracting-allowed']
  /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingProcess/cac:ProcessJustification[cbc:ProcessReasonCode/@listName='no-esubmission-justification']
  /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingProcess/cac:FrameworkAgreement/cac:SubsequentProcessTenderRequirement[cbc:Name/text()='buyer-categories']
  /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingTerms/cac:AllowedSubcontractTerms[cbc:SubcontractingConditionsCode/@listName='subcontracting-obligation']
  

• On Procurement Information Notices

  /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Part']/cac:TenderingTerms/cac:CallForTendersDocumentReference[not(cbc:DocumentType/text()='restricted-document')]
  /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Part']/cac:TenderingTerms/cac:CallForTendersDocumentReference[cbc:DocumentType/text()='restricted-document']
  /*/ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/efext:EformsExtension/efac:Organizations/efac:Organization/efac:Company[(cac:PartyIdentification/cbc:ID/text() = //  efac:TenderingParty/efac:Tenderer/cbc:ID/text()) or (cac:PartyIdentification/cbc:ID/text() = //efac:TenderingParty/efac:Subcontractor/cbc:ID/text())][/*/ext:UBLExtensions/  ext:UBLExtension/ext:ExtensionContent/efext:EformsExtension/efac:NoticeSubType/cbc:SubTypeCode/text() = 'T02']
  

In the code list innovative-acquisition there are missing English translations for codes prod-innov and proc-innov

source - https://github.com/OP-TED/eForms-SDK/blob/develop/codelists/innovative-acquisition.gc

I have a notice (sub type 16) generated with Notice2, exported as XML, edited to be valid against XSD. The response from CVS (preview environment) for this notice contains also the validation BR-BT-00067-0104 with error "BT-67(a)-Procedure must contain one of the values of the code list exclusion-ground". The problem is that the code list used to test is not the correct one.

The correct code list I assume is this one: https://op.europa.eu/en/web/eu-vocabularies/dataset/-/resource?uri=http://publications.europa.eu/resource/dataset/criterion

But the TEST code list is:
normalize-space(.) = ('CRITERION.EXCLUSION.BUSINESS.ACTIVITIES_SUSPENDED', 'CRITERION.EXCLUSION.BUSINESS.BANKRUPTCY', 'CRITERION.EXCLUSION.BUSINESS.BANKRUPTCY_ANALOGOUS', 'CRITERION.EXCLUSION.BUSINESS.CREDITORS_ARRANGEMENT', 'CRITERION.EXCLUSION.BUSINESS.INSOLVENCY', 'CRITERION.EXCLUSION.BUSINESS.LIQUIDATOR_ADMINISTERED', 'CRITERION.EXCLUSION.CONFLICT_OF_INTEREST.EARLY_TERMINATION', 'CRITERION.EXCLUSION.CONFLICT_OF_INTEREST.MISINTERPRETATION', 'CRITERION.EXCLUSION.CONFLICT_OF_INTEREST.PROCEDURE_PARTICIPATION', 'CRITERION.EXCLUSION.CONFLICT_OF_INTEREST.PROCEDURE_PREPARATION', 'CRITERION.EXCLUSION.CONTRIBUTIONS.PAYMENT_OF_SOCIAL_SECURITY', 'CRITERION.EXCLUSION.CONTRIBUTIONS.PAYMENT_OF_TAXES', 'CRITERION.EXCLUSION.CONVICTIONS.CHILD_LABOUR-HUMAN_TRAFFICKING', 'CRITERION.EXCLUSION.CONVICTIONS.CORRUPTION', 'CRITERION.EXCLUSION.CONVICTIONS.FRAUD', 'CRITERION.EXCLUSION.CONVICTIONS.MONEY_LAUNDERING', 'CRITERION.EXCLUSION.CONVICTIONS.PARTICIPATION_IN_CRIMINAL_ORGANISATION', 'CRITERION.EXCLUSION.CONVICTIONS.TERRORIST_OFFENCES', 'CRITERION.EXCLUSION.MISCONDUCT.MARKET_DISTORTION', 'CRITERION.EXCLUSION.MISCONDUCT.MC_PROFESSIONAL', 'CRITERION.EXCLUSION.NATIONAL.OTHER', 'CRITERION.EXCLUSION.SOCIAL.ENVIRONMENTAL_LAW', 'CRITERION.EXCLUSION.SOCIAL.LABOUR_LAW', 'CRITERION.EXCLUSION.SOCIAL.SOCIAL_LAW')
response_1675434226004.zip

Rule BR-BT-00145-0100 checks whether the date of the contract (BT-145-Contract) is earlier than the dispatch date of the notice (BT-05(a)-notice). This means that the date of the contract may only be in the past, otherwise the rule strikes. Up to now, however, it was the case that the contract date could only not be in the future, but the contract date and the notice dispatch date could be identical.

Is this the way it should be or is it a mistake?

Hi,

in SDK VErsion 1.5 the code rl-aut is missing although it is listed in the respective codelist

This might be a bug and leads to false validation.

thx in advance

I would have expected it to match the recently released 1.6.0.

We noticed that fields BT-54 and BT-57 are not placed in the correct groups:
BT-54 should be placed in group ND-OptionsDescription and not in GR-Lot-ContractExtension
BT-57 should be placed in group GR-Lot-ContractExtension and not in ND-OptionsDescription
And shouldn’t ND-OptionsDescription be at the same level as GR-Lot-ContractExtension, rather then being nested in the latter?

Hi!
While working with SDK 1.6 I found the code OP_DATPRO in currency.gc.
I guess it should have only been added to eu_programme.gc.

BT-661 (lot) is defined as indicator type in the fields.json

ref: https://github.com/OP-TED/eForms-SDK/blob/develop/fields/fields.json#L16670-L16690

But in the schema this property is defined as TextType array

https://github.com/OP-TED/eForms-SDK/blob/develop/schemas/maindoc/UBL-ContractAwardNotice-2.3.xsd#L61
https://github.com/OP-TED/eForms-SDK/blob/develop/schemas/common/UBL-CommonAggregateComponents-2.3.xsd#L4999-L5001
https://github.com/OP-TED/eForms-SDK/blob/develop/schemas/common/UBL-CommonAggregateComponents-2.3.xsd#L2221 (array minOccurs="0" maxOccurs="unbounded" )

and finally limit description is defined as text type:
https://github.com/OP-TED/eForms-SDK/blob/develop/schemas/common/UBL-CommonBasicComponents-2.3.xsd#L3551-L3555

We were expecting this field to be indicator type in XSD

Hi,

In UBL-CommonAggregateComponents-2.3 XSD

PartyType -type contains property cac:AgentParty which has type of PartyType and references back to iself:

Is this intentional ?

We have a Schematron error with code rule|text|BR-OPT-00310-0100 (efac:TenderingParty/cbc:ID) but can not find it in any translation file.

Is it missing?

We are working on an engine to turn physical models into conceptual models (for the purpose of copying information from one notice to another). At the start of the engine’s run, we have a virtually empty conceptual model (containing nothing but 1 sole instance of ND-Root) and an XML string with values (the notice itself - e.g. one of the examples provided in the SDK). At the end of the run, the conceptual model should be a tree of nodes (or rather, node instances) and fields (field values) in such a way that it should be possible to re-generate the original XML.

For a notice of subtype X, our approach is as follows: using the visual model from X’s notice-type json file "X.json" (not to be confused with the values provided by the user collected via the UI, which we call a visual model instance, but which is not used in this part of our engine), build the conceptual model node by node by running XPath queries on the XML to select instances of nodes and values of fields.

We treat the visual model as a tree of nodes. We crawl it using a stack, seeded with the entries of "metadata" and "contents". For each node we visit, distinguish between: field, visual group or repeatable node group.
For visual groups: simply add entries of "contents" to the stack (nothing more).
For repeatable node groups and fields: run the XPath of the corresponding node/field (retrieved from fields.json) on the XML and create nodes in the conceptual model for each match. For each matched node instance, also add the entries of "contents" to the stack. (Our stack consists of instances of a structure that brings together pointers to the conceptual model, the visual model and XML elements.)

When adding a field/node to the conceptual model, it is possible that the field/node’s parent node does not yet exist. In such cases, we first try to add the parent node. The parent itself might also not exist, so we try the parent’s parent recursively until we find an ancestor that we can add. In other words: we construct a node path of "missing nodes" (= the field/node and 0 or more of its ancestors) and then add all of them to the conceptual model.

Based on the following part of the developer guide...

An input-field will never have a repeatable ancestor in the visual model unless that repeatable ancestor corresponds to a repeatable node that is also an ancestor of the corresponding field. Therefore, it is safe to assume that whenever you visit an input-field, that any repeatable ancestors will have already been visited and their corresponding nodes will have already been created in the conceptual model.

...it was our understanding that none of theses "missing nodes" should be repeatable, but while testing our engine, we have ran into situations where this does seem to be the case. For example, in SDK 1.6.0, for notice subtype 16, using cn_24_maximal as XML, our engine reports the following anomalies ("missing" yet repeatable nodes):

ND-NonEsubmission
ND-LotRestrictedDocuments
ND-LotDocumentsReference
ND-ProcedureMainClassification
ND-LotMainClassification

Indeed, "ND-ProcedureMainClassification" is repeatable but it does not appear explicitly in 16.json though "BT-262-Procedure" (which has ND-ProcedureMainClassification as parent) does.

Could this possibly be a mistake in the SDK (in the sense that "ND-ProcedureMainClassification" should be somewhere in 16.json), or are we missing something?

Currently (at least until 0.6.2), you do a GitHub release, but you do not provide a release artifact.

Please provide one, which is compiled version of the sources. At minimum you could exclude all the build specific stuff like .mvn .github etc.

The publication flow in TEST seems to be paused. My submitted notices are not published for 2 days. Could you confirm?

according to CEllex, BT-10 is CM conditionally mandatory,

the schematron rules for the condition are inconsistant:

Example Notice type 2 but occurs for several notice types
Line 595:
BT-10-Procedure-Buyer is mandatory for a notice with subtype 2 under the condition: Buyer Legal Type (BT-11-Procedure-Buyer) is not "Body governed by public law", "Body governed by public law, controlled by a central government authority", "Body governed by public law, controlled by a local authority", "Body governed by public law, controlled by a regional authority", "Central government authority", "Defence contractor", "EU institution, body or agency", "European Institution/Agency or International Organisation", "Group of public authorities", "International organisation", "Local authority", "Organisation awarding a contract subsidised by a contracting authority", "Organisation awarding a contract subsidised by a central government authority", "Organisation awarding a contract subsidised by a local authority", "Organisation awarding a contract subsidised by a regional authority", "Regional authority" or "Regional or local authority"

line 639 same condition but "forbidden" as result
BT-10-Procedure-Buyer is forbidden for a notice with subtype 2 under the condition: Buyer Legal Type (BT-11-Procedure-Buyer) is not "Body governed by public law", "Body governed by public law, controlled by a central government authority", "Body governed by public law, controlled by a local authority", "Body governed by public law, controlled by a regional authority", "Central government authority", "Defence contractor", "EU institution, body or agency", "European Institution/Agency or International Organisation", "Group of public authorities", "International organisation", "Local authority", "Organisation awarding a contract subsidised by a contracting authority", "Organisation awarding a contract subsidised by a central government authority", "Organisation awarding a contract subsidised by a local authority", "Organisation awarding a contract subsidised by a regional authority", "Regional authority" or "Regional or local authority"

Please answer my question in the previous discussion. Seems BT-531-Lot has incorrect visibility information.

Discussed in #257

As version 1.0.0 is out, it may be time to remove the disclaimer in the top of the project readme.

We intend to use object constructors and this field turns it into a circular reference. Could something be done about this particular field?

"id" : "OPT-300-Procedure-SProvider",
"parentNodeId" : "ND-ProviderParty",
"name" : "Service Provider Technical Identifier Reference",
"btId" : "OPT-300",
"xpathAbsolute" : "/*/cac:ContractingParty/cac:Party/cac:ServiceProviderParty/cac:Party/cac:PartyIdentification/cbc:ID",

Problem:

When we use our notice rendering engine, some conceptual node is rendered as two separate xml nodes (<cac:CallForTendersDocumentReference>), but it according to the XSDs it should be a single one.

<cac:TenderingTerms>
  <!-- ... -->
  <cac:CallForTendersDocumentReference>
    <cbc:ID>TenderDocumentRef-LOT-0000</cbc:ID>
    <cac:Attachment>
      <cac:ExternalReference>
        <cbc:URI>https://tst.publicprocurement.be/supplier/enterprises/0/tendering-workspaces/publication-workspace-detail/9352d0d7-a9a9-4f2d-83e3-9349184e3751/documents</cbc:URI>
      </cac:ExternalReference>
    </cac:Attachment>
  </cac:CallForTendersDocumentReference>
  <!-- ... -->
</cac:TenderingTerms>

<cac:TenderingTerms>
  <!-- ... -->
  <cac:CallForTendersDocumentReference>
    <cbc:ID>TenderDocumentRef-LOT-0000</cbc:ID>
  </cac:CallForTendersDocumentReference><!-- should not be here! -->
  <cac:CallForTendersDocumentReference><!-- should not be here! -->
    <cac:Attachment>
      <cac:ExternalReference>
        <cbc:URI>https://tst.publicprocurement.be/supplier/enterprises/0/tendering-workspaces/publication-workspace-detail/9352d0d7-a9a9-4f2d-83e3-9349184e3751/documents</cbc:URI>
      </cac:ExternalReference>
    </cac:Attachment>
  </cac:CallForTendersDocumentReference>
  <!-- ... -->
</cac:TenderingTerms>

Investigation

Our conceptual model looks as follows:

{
  "nodeId": "ND-LotTenderingTerms",
  "children": [
    {
      "fieldId": "BT-744-Lot",
      "parentId": "ND-LotTenderingTerms",
      "value": "false"
    },
    {
      "fieldId": "BT-97-Lot",
      "parentId": "ND-LotTenderingTerms",
      "value": "ENG"
    },
    {
      "nodeId": "ND-LotProcurementDocument",
      "children": [
        {
          "fieldId": "OPT-140-Lot",
          "parentId": "ND-LotProcurementDocument",
          "value": "TenderDocumentRef-LOT-0003"
        }
      ]
    },
    {
      "nodeId": "ND-TenderRecipient",
      "children": [
        {
          "fieldId": "BT-18-Lot",
          "parentId": "ND-TenderRecipient",
          "value": "test"
        }
      ]
    },
    {
      "nodeId": "ND-LotDocumentsReference",
      "children": [
        {
          "fieldId": "BT-15-Lot",
          "parentId": "ND-LotDocumentsReference",
          "value": "https://tst.test.be/"
        }
      ]
    }
  ]
}

This is build based on the fields.json metadata:

{
  "id" : "ND-LotProcurementDocument",
  "parentId" : "ND-LotTenderingTerms",
  "xpathAbsolute" : "/*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingTerms/cac:CallForTendersDocumentReference",
  "xpathRelative" : "cac:CallForTendersDocumentReference",
  "repeatable" : true
},
{
  "id" : "ND-LotDocumentsReference",
  "parentId" : "ND-LotTenderingTerms",
  "xpathAbsolute" : "/*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingTerms/cac:CallForTendersDocumentReference[not(cbc:DocumentType/text()='restricted-document')]",
  "xpathRelative" : "cac:CallForTendersDocumentReference[not(cbc:DocumentType/text()='restricted-document')]",
  "repeatable" : true
},

// ...

{
  "id" : "OPT-140-Lot",
  "parentNodeId" : "ND-LotProcurementDocument",
  "name" : "Procurement Documents ID",
  // ...
},
{
  "id" : "BT-15-Lot",
  "parentNodeId" : "ND-LotDocumentsReference",
  "name" : "Documents URL",
  // ...
}

Note that the fields OPT-140-Lot and BT-15-Lot are children of the nodes ND-LotProcurementDocument and ND-LotDocumentsReference, respectively. Both nodes are repeatable independent nodes under ND-LotTenderingTerms.

Issue

We would expect that these fields to be part of a single repeatable conceptual subtree instead of being independently repeatable in the conceptual model. As far as we can tell this is already the case in the visual metadata model and in the XSDs.

In PrioInformationNotice XSD cac:OriginatorCustomerParty is defined as a list of OriginatorCustomerParty types.
( ref: https://github.com/OP-TED/eForms-SDK/blob/develop/schemas/maindoc/UBL-PriorInformationNotice-2.3.xsd#L53-L55 )
In ContractNotice XSD its also defined as list of OriginatorCustomerParty types.
(ref: https://github.com/OP-TED/eForms-SDK/blob/develop/schemas/maindoc/UBL-ContractNotice-2.3.xsd#L52-L54)

But in contract award notice type it is defined as single type "maxOccurs=1"
(ref: https://github.com/OP-TED/eForms-SDK/blob/develop/schemas/maindoc/UBL-ContractAwardNotice-2.3.xsd#L58)

Is this intentional?

In the CELEX -no matter what version- theBT-s are groupt within each BG and the colums give Info in which notive Type the BG/BT is Optional, Conditionaly Mandatory, Existing Mandatory or Mandatory. So far so good.
None of the BTs or BGs are devided in the CELEX. In the SDK -also different Versions- however, ther are Rules for different "Parts" of BTs. Eg. BT-09 a and BT-09 b or BT-712 a and BT-712b. Where do theses divisions come from and where can Info on the parted BTs can be retrieved?

In Procedure, Group of Lots, Lot & Part related information :: TED Developer Documentation CalculationExpression is a sibling to AwardCriteriaComplicatedLot.

There are xml examples in the SDK that show both variants:
cn-social_24.xml

can_24_minimal.xml

Some SVRL example reports contain failed-asserts with attribute location="".

Context

eForms-SDK v.1.5.0

Details

In some SVRL example reports (/examples/reports/), a few failed-assert tags have attribute location="" instead of an XPath expression that points to the error in the notice. I've listed:

• INVALID_can_24_stage-1.svrl, line 582 and 603
• INVALID_cn_24_stage-1.svrl, line 621 and 642
• INVALID_pin-buyer_stage-1.svrl, line 294
• INVALID_pin-only_stage-1.svrl, line 346 and 367

For example, in `INVALID_can_24_stage-1.svrl contains

   <svrl:failed-assert id="BR-BT-00026-0605"
                       location=""
                       role="ERROR"
                       test="normalize-space(.) = ('cpv')">
      <svrl:text>rule|text|BR-BT-00026-0605</svrl:text>
   </svrl:failed-assert>

   <svrl:failed-assert id="BR-BT-00026-0609"
                       location=""
                       role="ERROR"
                       test="normalize-space(.) = ('cpv')">
      <svrl:text>rule|text|BR-BT-00026-0609</svrl:text>
   </svrl:failed-assert>

The triggered rules are BR-BT-00026-0605, BR-BT-00026-0607, BR-BT-00026-0609.

Expected value

In INVALID_can_24_stage-1.svrl:

   <svrl:failed-assert id="BR-BT-00026-0605"
                       location="/ContractAwardNotice/cac:ProcurementProject/cac:MainCommodityClassification/cbc:ItemClassificationCode/@listName"
                       role="ERROR"
                       test="normalize-space(.) = ('cpv')">
      <svrl:text>rule|text|BR-BT-00026-0605</svrl:text>
   </svrl:failed-assert>

   <svrl:failed-assert id="BR-BT-00026-0609"
                       location="/ContractAwardNotice/cac:ProcurementProjectLot/cac:ProcurementProject/cac:MainCommodityClassification/cbc:ItemClassificationCode/@listName"
                       role="ERROR"
                       test="normalize-space(.) = ('cpv')">
      <svrl:text>rule|text|BR-BT-00026-0609</svrl:text>
   </svrl:failed-assert>

Description

In the schematrons, asserts

• BR-BT-00004-0052,
• BR-BT-00701-0052,
• BR-BT-01252-0052

check that the content of the node matches the regular expression ^[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89ab][a-f0-9]{3}-[a-f0-9]{12}$

In example SVRL reports, the regex included in the failed asserts is ^[a-f0-9]8-[a-f0-9]4-4[a-f0-9]3-[89ab][a-f0-9]3-[a-f0-9]12$. The regex no longer includes the curly braces.

Example

In static/validation-stage-3b.sch:

<rule context="/*/cbc:ID[@schemeName='notice-id']">
        <assert id="BR-BT-00701-0052" role="ERROR" test="matches(normalize-space(.),'^[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89ab][a-f0-9]{3}-[a-f0-9]{12}$')">rule|text|BR-BT-00701-0052</assert>
</rule>

In example/reports/INVALID_can_24_stage-2.svrl:

<svrl:fired-rule context="/*/cbc:ID[@schemeName='notice-id']"/>
<svrl:failed-assert id="BR-BT-00701-0052"
                   location="/ContractAwardNotice/cbc:ID"
                   role="ERROR"
                   test="matches(normalize-space(.),'^[a-f0-9]8-[a-f0-9]4-4[a-f0-9]3-[89ab][a-f0-9]3-[a-f0-9]12$')">
    <svrl:text>rule|text|BR-BT-00701-0052</svrl:text>
</svrl:failed-assert>

We are looking into a meta data driven implementation of eForms. We came across some fields which appear to be in a different location in the XSD then the fields.json says they should be.

Are we using the field.json in the wrong way?

I've added some examples below, which occur in noticesubtypes 23 & 24.

Field id: BT-46-Lot
Absolute Path: /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingTerms/cac:AwardingTerms/cac:Prize/cac:TechnicalCommitteePerson/cbc:FamilyName
Actual Path in the XSD: /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingTerms/cac:AwardingTerms/cac:TechnicalCommitteePerson/cbc:FamilyName

Field id: ND-334
Absolute Path: /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingTerms/cac:AwardingTerms/cac:EconomicOperatorShortList
Actual Path in the XSD: /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingTerms/cac:EconomicOperatorShortList

In 1.6.0 the group "GR-Lot-Purpose" received the nodeId "ND-LotTenderingProcess".

According to https://docs.ted.europa.eu/eforms/latest/notice-types/index.html my assumption is that all fields having this node as an ancestor should be a part of this group, but for some of the fields like BT-131(d)-Lot and BT-131(t)-Lot that is not the case.

We feel it would make sense to move BT-536 duration start date up one level, as it is used both when users give a duration end date (BT-537) as when they provide a duration period (BT-36). BT-537 and BT-36 are meaningless without BT-536.

We also think that the codelist foreseen in BT-538 should appear before any other duration related fields: if the duration is still “unknown”, or “unlimited”, it makes no sense to ask for any more detailed duration details (BT-536, BT-537, BT-36).

BT-23-Lot is defined as code type in the fields.json (codelist "eforms-contract-nature")

ref: https://github.com/OP-TED/eForms-SDK/blob/develop/fields/fields.json

In some notice-type json files the display type of this property is defined as radio

https://github.com/OP-TED/eForms-SDK/blob/develop/notice-types/16.json

The correct display type would be "COMBOBOX", as in BT-23-Procedure or BT-531-Lot

Looking at the documentation here:

https://docs.ted.europa.eu/eforms/latest/schema/procedure-lot-part-information.html#strategicProcurementSection

it shows that the BT-06 is repeated once for each type of strategic procurement objective.

However, this example file:

https://github.com/OP-TED/eForms-SDK/blob/develop/examples/notices/cn_24_maximal.xml

have individual Lots with environmental-impact, social-impact and innovative-acquisition but only one BT-06 (env-imp).

Question 1: Is it correctly understood that BT-06 should be provided once for each type of strategic objective in the notice (like the documentation) and that the sample file is incorrect?

Question 2: The BT-06 codelist has a value "none" as an option, however BT-06 is not mandatory. Is the omission of BT-06 semantically equivalent to providing BT-06 with value 'none'?

Schematron (SDK 1.5) calls for
BT-10-Procedure-Buyer must contain one of the values of the code list authority-activity
The attribute "listName" must be present for BT-10-Procedure-Buyer

TED Developers Doc names BT-10 " Activity Authority" and has some codes, but only in English.

In https://github.com/OP-TED/eForms-SDK/tree/develop/codelists there is neither a Codelist for "Authority Activity" nor anything related to "Procedure Buyer"
Could you please claryfy where to find the Codelist for BT-10?

THX

We noticed a few lines which look like they are missing a ':'.

For example in 29.efx, section 6:

SDK version 1.4 used.

The subtypes E1, E2, E3, E4, E5 are not found in the notice-types.json.
But interestingly they exist in the translations file and also in the CELEX_32019R1780_EN_ANNEX_TABLE2_Extended.xlsx
Could you please add these types also.

English translation is showing for 5.1.16 on preview render sdk 1.5.

Intro

The schemeName attribute was added to some fields in release 1.6.0

I notice that the attribute was only added to those fields that are the id field of an idScheme, instead of to all fields that would need a "schemeName"="..." attribute in the xml:

schemeName attribute included in 1.6.0

• idScheme id field:

{
    "id" : "OPT-321-Tender",
    "type" : "id",
    "idScheme" : "TEN",
    "schemeName" : "tender",
}

Some fields without schemeName that need it in the xml representation:

• id-ref fields:

{
    "id" : "BT-13714-Tender",
    "type" : "id-ref",
    "idSchemes" : [ "GLO", "LOT" ],
    // "schemeNames": [ "LotsGroup", "Lot" ]
}

• Internal Identifier fields:

{
    "id" : "BT-22-Lot",
    "name" : "Internal Identifier",
    "type" : "id",
    // "schemeName": "InternalID"
}

• specific metadata fields:

{
    "id" : "BT-701-notice",
    // "schemeName": "notice-id"
}

{
    "id" : "OPP-010-notice",
    // "schemeName": "ojs-notice-id"
}

{
    "id" : "OPP-011-notice",
    // "schemeName": "ojs-id"
}

I assume Notice2 app is in production but there is no way to use it in a production environment. Even in preview environment it's not possible to obtain a valid notice even if a user fill in data with caution.

Main issue: ta application is not yet able to validate, at GUI level, the elements that are choices in XSD. For example parameters for award criteria - the user has no clue that it should choose only one code because the GUI suggest it can be multiple choices. Also the Organization indicators for Group Leader, Acquiring CPB Awarding CPB OR Natural Person are set to false - user didn't fill anything in GUI but this list is invalid because is a choice in XSD - please see the pictures.

This is a major issue because the GUI seems not to be able to conform with XSD. Also the app is not able to provide errors regarding XSD validation.

Second major issue: the Validation (submit to CVS) is not working - there is a generic error that says that not all mandatory fields are present but there is no indication which one are missing.

Another major issue: the application is not able to adapt dynamically when user fill in data. For example you can choose that there is no electronic auction but still fill in data describing the electronic auction. This can be easily avoided by user but there are other situations more tricky: contract duration can be filled in as a start date and date but in the same time as a period. This kind of inconsistence I suppose will be detected by CVS but, again, the validation is not working.

These issues should be fixed because this application is a good source of reference and a good one for fill in data and obtain a lot of XMLs for different form types and different situations. It is important for helping the development process of eSenders systems, especially the systems that can't integrate the SDK because of their architecture.

I can not find any entry on BT-08 (Organisation Role) in fields.json. However, I can find BT-08 in many translation files.

Is this a bug?

Hello,

It seems that we have fields for exclusion grounds only at procedure level, BT-67(a)-Procedure and BT-67(b)-Procedure at /*/cac:TenderingTerms/cac:TendererQualificationRequest/cac:SpecificTendererRequirement/cbc:TendererRequirementTypeCode[@listname='exclusion-ground']

But we need to express some of the exclusion grounds, more specific category C from ESPD at LOT level. I have made an example that is validated OK by the CVS. But I didn't find any fields for this, something like BT-67(a)-Lot and BT-67(b)-Lot in Fields.json

It will be valid for production such an approach?

Please see the form and the response.

Thank you
Alex Mohora

Exemple_Exclusion_Grounds_Lot.zip

Currently

You provide schmetron rules/asserts the following way:

<assert id="ND-GazetteReference-1" role="ERROR" test="count(cac:AdditionalDocumentReference) = 0">rule|message|ND-GazetteReference-1</assert>

and provide the translations in another files like rule_${iso-lang}

A much simpler way and more easy to comprehend for schematron developers would be instead:

<assert id="ND-GazetteReference-1" role="ERROR" test="count(cac:AdditionalDocumentReference) = 0">The element cac:AdditionalDocumentReference is not allowed under /*</assert>

with default messages in English (especially for the ones who just want to use the Schematrons as-is )

Then you just need:
e.g. in rule_fr.xml an entry as follows:

<entry key="ND-GazetteReference-1">French translation is actually missing (another bug I guess)</entry>

where the entry key is the id of the schmetron rule.

Advantages:

• There is at least one original message in schematron -> direct comprehension
• hence a bug like not having a french translation gives developers at least an English message instead of a cryptic rule|message|ND-GazetteReference-1
• Your Schematrons are more usable out of the context of the SDK and not everyone has to always make the translation before being able to understand SVRL output. -> Added value

Based on the documentation and documentation example from here:
https://docs.ted.europa.eu/eforms/latest/codelists/index.html#_codelists_in_eforms_notice_xml

ProcurementTypeCode should have list name of "contract-nature" there are many fields in fields.json which do not have listname attribute set in the path, but they have code list defined as a value.
Even the example shown in the documentation is missing attribute name?

one example:
https://github.com/OP-TED/eForms-SDK/blob/develop/fields/fields.json#L11433-L11485

Schema:

How can we programmically detect what list name should be used in each field?

Eforms code list example:
https://github.com/OP-TED/eForms-SDK/blob/develop/codelists/contract-nature_eforms-contract-nature.gc#L6

Now those eforms code lists have name "eforms-something-foo-bar" but the listName in the data should be "something-foo-bar"? Does this rule apply to all eforms specific code lists?

Could there be a field in the config that tells the name of the code list to be used in the data? Or does the data have different listName even if the value is selected from the same code list per schema location?

The current codelist-definition for BT-01-notice is:

"codeList" : {
"value" : {
"id" : "eforms-legal-basis",
"type" : "flat"
},
"severity" : "ERROR"
}

the codelist-Folder contains no codelist with that name - only legal-basis and legal-basis_eforms-legal-basis.

In accordance to other codelist-defintions in fields.json, should the codelist-definition for BT-01-notice be changed into
"codeList" : {
"value" : {
"id" : "eforms-legal-basis",
"type" : "flat"
"parentId" : "legal-basis"
},
"severity" : "ERROR"
}
?

Out of curiousity, will this project move to https://code.europa.eu ? Seems to be a more obvious choice now than US-based GitHub.

  Hi !

in xsd CompanyType ( as in Touchpoint) there is one ( not mandatory ) PostalAddress and Contact
<xsd:complexType name="CompanyType">
xsd:sequence

		<xsd:element ref="cac:PostalAddress" minOccurs="0" maxOccurs="1"/>

		<xsd:element ref="cac:Contact" minOccurs="0" maxOccurs="1"/>
	</xsd:sequence>

in Conceptual Model , under ND-Company and ND-Touchpoint there are many fields like
BT-513-Organization-Company cac:PostalAddress/cbc:CityName
BT-512-Organization-Company cac:PostalAddress/cbc:PostalZone
BT-507-Organization-Company cac:PostalAddress/cbc:CountrySubentityCode
BT-514-Organization-Company cac:PostalAddress/cac:Country/cbc:IdentificationCode

BT-502-Organization-Company cac:Contact/cbc:Name
BT-506-Organization-Company cac:Contact/cbc:ElectronicMail
BT-503-Organization-Company cac:Contact/cbc:Telephone
BT-739-Organization-Company cac:Contact/cbc:Telefax

What do you think to set a node for PostalAddress and the Contact ?
Just to avoid some ugly "if" in the code ..
Thanks
Renato

Originally posted by @rengit62 in #163