Notice Types
Notice subtypes
The eForms Regulation defines, in table 1 of its annex, a list of types of procurement notices.
In order to avoid confusion with the more general notion of "notice type" (contract notice, contract award, PIN, etc.), we are designating each specific item as "notice subtype". So a notice subtype corresponds to a specific column in table 2 of the annex to the eForms regulation. |
The eForms SDK provides this information in the notice-types
folder, as a structured JSON file named notice-types.json
.
This file contains some metadata, followed by the list of notice subtypes, and the indication of the corresponding XML schema.
{
"ublVersion" : "2.3", (1)
"sdkVersion" : "eforms-sdk-0.5.0", (2)
"metadataDatabase" : { (3)
"version" : "0.2.16",
"createdOn" : "2021-11-04T11:11:11"
},
"noticeSubTypes" : [
{
"documentType" : "PIN", (4)
"legalBasis" : "32014L0024", (5)
"formType" : "planning", (6)
"type" : "pin-buyer", (7)
"description" : "Notice of the publication of a prior (...)", (8)
"subTypeId" : "1", (9)
"_label" : "notice|name|1", (10)
"viewTemplateIds" : [ "1", "summary" ] (11)
},
...
],
"documentTypes" : [
{
"id" : "PIN", (12)
"namespace" : "urn:oasis:names:specification:ubl:schema:xsd:PriorInformationNotice-2", (13)
"rootElement" : "PriorInformationNotice", (14)
"schemaLocation" : "schemas/maindoc/UBL-PriorInformationNotice-2.3.xsd", (15)
"additionalNamespaces" : [ (16)
{
"prefix" : "cac", (17)
"uri" : "urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2", (18)
"schemaLocation" : "schemas/common/UBL-CommonAggregateComponents-2.3.xsd" (19)
},
...
]
},
...
]
}
1 | Version of the UBL standard used. |
2 | Version of the eForms SDK the file belongs to. |
3 | Version number and date of the data used to create this file. |
4 | Document type of the notice subtype, used to determine the XML namespace and root element of the XML notice. |
5 | Legal basis for the notice subtype. |
6 | The standard form for the notice subtype. |
7 | The notice type for the notice subtype. Values are from the "notice type" codelist. |
8 | Description of the notice subtype, from the eForms regulation. |
9 | Identifier of the notice subtype. |
10 | Identifier of the label for the name of the notice subtype. The label is available in the translations folder. |
11 | List of identifiers of the view templates that can be used to visualise a notice of this subtype. |
12 | Identifier of the document type. |
13 | XML namespace for the document type. |
14 | Root XML element for the document type. |
15 | Location of the XSD file that contains the definition of the root element, relative to the root of the SDK. |
16 | Additional namespaces used in an XML instance of the document type. |
17 | Prefix to use in the declaration of the additional namespace. |
18 | Full URI of the additional namespace. |
19 | Location of the XSD file that contains the definition of the elements in the namespace, relative to the root of the SDK. |
From the information visible in the example above, we can see that the notice subtype 1 has the document type PIN
, so the root element in the XML is PriorInformationNotice
.
The definition of this root element is in the file indicated by the schemaLocation
property.
Definition of a notice subtype
For each notice subtype, we define the content and structure of the form that notice authors will fill in. We provide this definition as a set of JSON files, with one file per notice subtype.
Those files are available in the eForms SDK, in the folder /notice-types
, and are named as follows:
<subTypeId>.json
These files reference the fields contained in the form via their identifier. The information for every field is centralised in the field repository.
Overall structure
The definition of a notice subtype has 2 parts:
-
metadata
, contains a flat list of readonly or hidden fields the values of which are known before the notice is created (and therefore can be pre-filled). -
content
, contains the fields that should be rendered on the screen for notice authors to fill-in. The fields are organised in nested groups providing in this way a hierarchical structure that the notice author should be presented with, in order to navigate the notice while filling it in.
{
"ublVersion" : "2.3",
"sdkVersion" : "0.7.0",
"metadataDatabase" : {
"version" : "0.4.179",
"createdOn" : "2022-06-30T17:37:21"
},
"noticeId" : "10", (1)
"metadata" : [ (2)
{
"id" : "BT-02-notice",
"contentType" : "field",
"displayType" : "COMBOBOX",
"description" : "Notice Type",
"_label" : "field|name|BT-02-notice",
"readOnly" : true
},
...
],
"content" : [ { (3)
"id" : "GR-ContractingAuthority",
"contentType" : "group",
"displayType" : "SECTION",
"description" : "Contracting Authority",
"_label" : "group|name|GR-ContractingAuthority",
"content" : [
... (4)
]}
]
}
1 | noticeId is the notice subtype identifier (the same as the filename). |
2 | metadata is a flat list of fields with known values. |
3 | content is a hierarchical list of of "content elements" (fields organised in a hierarchy of groups ) forming the visual structure of the notice.. |
4 | Content elements can be nested. |
Structure of metadata
Section
The metadata section is a flat list of fields, the values of which are known before the notice is created. The fields are either marked as readOnly
or hidden
. A field is marked as _repeatable
if it can occur multiple times in the metadata.
[
{
"id" : "BT-02-notice",
"contentType" : "field",
"displayType" : "COMBOBOX",
"description" : "Notice Type",
"_label" : "field|name|BT-02-notice",
"readOnly" : true
}, {
"id" : "BT-03-notice",
"contentType" : "field",
"displayType" : "COMBOBOX",
"description" : "Form Type",
"_label" : "field|name|BT-03-notice",
"readOnly" : true
}, {
"id" : "BT-04-notice",
"contentType" : "field",
"displayType" : "TEXTBOX",
"description" : "Procedure Identifier",
"_label" : "field|name|BT-04-notice",
"readOnly" : true
},
...
]
Structure of content
Section
A content element can either represent a field
or a group
of fields as indicated by its contentType
property. A content element of type group
can contain nested group
elements (as well as field
elements).
Every field
element represents a valid eForms field. The id
property of field
elements always contains the eForms field’s identifier and can be used to retrieve the field’s metadata from the field repository (fields.json
).
Every group
element is primarily a visual/logical structure element. However, in some cases, a group
element may also correspond to an XML element (node
) in the notice XML file. In this case, a nodeId
property is provided indicating the identifier of the node
which can be used to retrieve node metadata from the xmlStructure
section of fields.json
.
The identifiers of group elements (indicated by their id property) always start with "GR-" and, (in contrast with the identifiers of field elements), do not point to any elements in fields.json . They are used however to encode the 'group` labels (translations).
|
"content" : [ {
"id" : "GR-ContractingAuthority",
"contentType" : "group",
"displayType" : "SECTION",
"description" : "Contracting Authority",
"_label" : "group|name|GR-ContractingAuthority",
"content" : [ {
"id" : "GR-ContractingAuthority-Buyer",
"contentType" : "group",
"nodeId" : "ND-ContractingParty",
"displayType" : "GROUP",
"description" : "Contracting Party related Information (URL, Legal Type, Contracting Type, Activity, …)",
"_label" : "node|name|ND-ContractingParty",
"_repeatable" : true,
"content" : [ {
"id" : "OPT-300-Procedure-Buyer",
"contentType" : "field",
"displayType" : "TEXTBOX",
"description" : "Buyer Technical Identifier Reference",
"_label" : "field|name|OPT-300-Procedure-Buyer"
}, {
"id" : "BT-11-Procedure-Buyer",
"contentType" : "field",
"displayType" : "COMBOBOX",
"description" : "Buyer Legal Type",
"_label" : "field|name|BT-11-Procedure-Buyer"
}, {
"id" : "BT-10-Procedure-Buyer",
"contentType" : "field",
"displayType" : "COMBOBOX",
"description" : "Activity Authority",
"_label" : "field|name|BT-10-Procedure-Buyer"
}, {
"id" : "BT-508-Procedure-Buyer",
"contentType" : "field",
"displayType" : "TEXTBOX",
"description" : "Buyer Profile URL",
"_label" : "field|name|BT-508-Procedure-Buyer"
},
...
]
},
...
]
},
...
]
The following table lists all available properties for groups and fields:
Properties of group
elements
id
|
The identifier of the group. |
description
|
The description of the |
contentType
|
Indicates that this content element is a group element. |
displayType
|
Indicates whether this |
nodeId
|
The property is only present in |
_identifierFieldId
|
Appears only if |
_captionFieldId
|
Appears only if |
_idScheme
|
Appears only if |
_schemeName
|
Appears only if |
_repeatable
|
Indicates that the user should be allowed to add multiple occurrences of this |
_label
|
The identifier of the label that should be used for this |
Properties of field
elements
id
|
The identifier of the eForms field associated with this |
description
|
The description of the |
contentType
|
Indicates that this content element is a |
displayType
|
Provides a hint on what type of input element should be displayed on the screen for filling the field. |
readOnly
|
Indicates whether or not the field should be editable by the user. The property is present only when its value is |
hidden
|
Indicates whether or not the field should be visible on the user’s screen. The property is present only when its value is |
valueSource
|
This property indicates that the value of this field should be a copy of the value of another field. It provides the identifier of the referenced field whose value should be copied over. It is most commonly used for hidden fields of type |
_idScheme
|
It appears only for the fields of type |
_idSchemes
|
This property appears only for fields of type |
_repeatable
|
Indicates whether or not the user should be allowed to create multiple instances of this field. The property is present only when its value is |
_label
|
The identifier of the label that should be used for this |
_presetValue
|
The known value that should be used to pre-fill this |
JSON and XML structure constraints
The purpose of the notice subtype definition is to abstract the form displayed to a notice author from the eForms XML notice generated by the system. While it can be slightly customized, it cannot have an arbitrary structure, it must be aligned with the eForms XML schema to some extent.
For instance, the number of repeatable groups (in a path from the content root to a field) in the JSON structure must match the number of repeatable parent elements (in a path from the document root to the field element/attribute) in the eForms XML schema.
There is no constraint on non-repeatable groups. An arbitrary number of intermediate, non-repeatable groups can be created to organize the notice fields in a more convenient way. Moreover, the fields of the same level of the repeatable structure (ignoring non-repeatable groups) can be specified in an arbitrary order.
It is even possible to split a repeatable XML element group into multiple repeatable JSON groups.
In such case, the XML element group must contain an (instance) identifier field (e.g. BT-137-Lot - Purpose Lot Identifier
), which is also contained in every JSON group part.