2.1.1.3

Data product publication: Provision - Data source endpoint provisioning

Assessment: Assess the availability of multiple data planes that support multiple protocols. Refer to D2.1 for an overview of the most used protocols. The higher the coverage, the higher the ranking.

note

The description of Test 2.1.1.3 was extracted from this page in the GitHub repository.
This file was last modified at 2026-06-24 15:37:50 UTC.

Information

• Phase 1

• Minimal? Yes

• Related KPIs:

  • Functional suitability: Can the provider integrate different data source methods (APIs, data bases, file systems, etc.)

• Evaluation Criteria:

N/A

Results

Fiware

note

The results for Test 2.1.1.3 for Fiware were extracted from this page in the GitHub repository.
This file was last modified at 2026-06-24 15:37:50 UTC.

Environment

This functionality has been tested in the IONOS Deployment

Tested quality metric and method

Comparative criteria (checklists, ...)

Expected output

Multiple protocols can be used in the data plane.

Results

Assessment

The data plane in the Fiware Connector is realized with the Apache APISIX component. Therefore all protocols and schemes supported by APISIX can be used with the Fiware Connector.

APISIX supports multiple protocols:

• HTTP
• TCP/UDP
• SSL
• gRPC
• Kafka
• Redis

Measured results

Notes

In addition to the available protocols, new protocals can be added to APISIX, see How to write your own protocol.

protoEMDS Final Stack (EDC-based)

note

The results for Test 2.1.1.3 for protoEMDS Final Stack (EDC-based) were extracted from this page in the GitHub repository.
This file was last modified at 2026-06-24 15:37:50 UTC.

Environment

This section identifies the technical context in which the protoEMDS Final Stack assessment is performed.

Field	Value
Assessment context	Integration phase assessment of the EMDS final technical infrastructure
Result perspective	protoemds_final_stack
Stack under assessment	protoEMDS Final Stack (EDC-based)
KPI1 area	Connector and data planes
Existing test ID	2.1.1.3
Level	Technical
ISO/IEC 25010 mapping	Compatibility, Reliability
Owner (tentative)	Carlos (i2CAT)
Reviewer	Wilhelm
Deployment model assessed	TBD
Target environment	TBD
EDC version / release	TBD
Connector deployment reference	TBD
Assessment evidence	TBD

The assessment should be completed using the deployment model for which evidence is realistically available. It is not mandatory to execute the same test in both CaaS and on-premise environments.

If only one deployment model is assessed, the other one should be marked as Not assessed.

Tested quality metric and method

This result reuses the existing stack-agnostic test definition in test.md and adds an protoEMDS Final Stack integration-assessment perspective.

It does not replace the historical stack-specific result files, such as result_edc_vc.md or result_fiware.md.

The quality metric, expected output and comparative criteria remain those defined by the original test. This result file should only capture the evidence and assessment outcome for the selected protoEMDS Final Stack deployment.

Test-specific assessment scope

Assess the availability of multiple data planes that support multiple protocols. Refer to D2.1 for an overview of the most used protocols. The higher the coverage, the higher the ranking.

Expected Output

Evaluate the level of support for the following data formats

• GTFS - Public dataset with direct download via HTTPS
• GTFS-RT - Public dataset via APIs
• DATEX-II - Flanders DATEX-II feed via APIs
• DATEX II Light - No available datasets for this data format, tests are skipped
• GBFS - Candidate GBFS source to be confirmed before execution. The previous EMEL reference is currently unavailable during the open data portal transition and should not be used as execution evidence until validated.
• WMS/WFS - Public dataset via APIs

Also access through APIs.

Access to private APIs should be tested using a representative private endpoint selected by the test executor or component owner. AMB Mobilitat may be used as an example if available, but the selected endpoint, authentication flow and access requirements must be documented before execution.

The execution evidence should document:

• the selected private endpoint or API route;
• the authentication method, without exposing API keys, tokens, credentials or secrets;
• the required request headers or token type, if applicable;
• the expected response status;
• a redacted example of the response payload;
• the component or owner confirming that the endpoint is representative for private API access.

Results

Assessment

Pending.

The assessment should be completed once consolidated technical evidence is available for the protoEMDS Final Stack deployment.

The result should clearly indicate which deployment model was assessed. It is acceptable to assess only one deployment model if evidence for the other deployment model is not available.

Deployment model assessed

Deployment model	Status	Evidence	Consolidated assessment
CaaS / IONOS-managed deployment	TBD	TBD	Complete this row only if evidence is collected from the IONOS-managed deployment. Otherwise mark as Not assessed.
On-premise deployment	TBD	TBD	Complete this row only if evidence is collected from an on-premise or locally managed deployment. Otherwise mark as Not assessed.

Measured results

Criterion	Description	Score (0-4)	Explanation
Functional Completeness	TBD	TBD	TBD
Functional Correctness	TBD	TBD	TBD
Functional Appropriateness	TBD	TBD	TBD

Functional Suitability Quality Metric Score: TBD

Notes

This result introduces an protoEMDS Final Stack perspective for the existing test 2.1.1.3 under the KPI1 area Connector and data planes.

This result should not be interpreted as part of the original Phase 1 / Phase 2 stack-comparison campaign. It is intended as an integration phase assessment of the current EMDS final technical infrastructure.

The assessment should be completed using consolidated technical evidence, such as endpoint responses, logs, screenshots, Postman/curl executions, GitHub issues, pull requests, repository references, deployment status or confirmation from the relevant component owner.

This result file was generated from the local test.md and, where available, the local result_edc_vc.md structure. EDC+VC-specific evidence, values and scores were intentionally not reused.

EDC+VC

note

The results for Test 2.1.1.3 for EDC+VC were extracted from this page in the GitHub repository.
This file was last modified at 2026-06-24 15:37:50 UTC.

Environment

EDC Connector v.0.7.1 within a local testbed. The tests are available in this Postman workspace.

Tested quality metric and method

If an asset can represent a data source X, then data source X can be provisioned.

Expected output

Evaluate the level of support for the following data formats

• GTFS - Public dataset with direct download via HTTPS
• GTFS-RT - Public dataset via APIs
• DATEX-II - Public dataset via APIs
• DATX II Light - No available datasets for this data format, tests are skipped
• GBFS - Public dataset via APIs
• WMS/WFS - Public dataset via APIs

Also access through APIs. Access to private APIs is tested using the AMB mobilitat endpoint.

Results

Assessment

All the tests are stored under this folder. A single, parameterized call is used for the entire batch of tests. Execute this tests by running the entire folder at once.

Measured results

The EDC-VC stack fully supports all 6 types of data planes explained in this test. As such, it is evaluated with the highest score in each of the criteria used to evaluate this test as shown in the table below.

Criterion	Description	Score (0-4)	Explanation
Functional Completeness	Technical requirements cover all the specified tasks and user objectives.	4	Artifacts can store a URL to any file format. The URL is stored by setting the field dataAddress.baseUrl.
Functional Correctness	Technical requirements meet results with the needed degree of precision.	4	Both publicly-accessible as well as private artifacts are supported. For the latter, different authentication methods are also provided, such as access through API keys which is supported through the attribute privateProperties.privateKey
Functional Appropriateness	Technical requirements facilitate the accomplishment of specified tasks and objectives.	4	All artifacts were created easily through a single API call passing the required information.

Overall score calculation: (4 + 4 + 4) / 3 = 4

Functional Suitability Quality Metric Score: 4