Decide what to put in offering publication wizard step 2: data access

[xamcost]

Hi there! The goal of this issue is to decide what to put in the second step of the offering publication wizard, dealing with the access to the data asset to be published. This step aims at gathering all information needed by the connector to fetch the data from its source. I guess most of these information will not appear in the offering self-description, but will be stored in the connector, right ?

⚠️ We (marketplace developers) assumed that data sources can only be accessed through HTTP requests! Please tell us if it isn't the case.

More precisely, this page should contain:

• URL to the data source + type of request (GET, POST, ...), required.
• an authentication/API key
• a body for the request (not needed for GET requests though).
• a list of headers to add to the request, optional.
• a list of query parameters to add to the request, optional.

Note that many of these parameters could be exposed on the consumer side as well, when requesting a transfer. For instance, the consumer could add a subpath to the request URL, as well as a body, headers and query parameters (potentially overwriting the one set by the provider). Please let us know if this should be the case. I suggest to discuss the interface for this in a separate issue.

At date of writing, this step looks like this:

[xamcost]

Pinging @psotres , @juanrasantana and @telsaleh for their feedback! Compared to step 1 described in #5 , there are much more questions to address here. Highlighting them:

This step aims at gathering all information needed by the connector to fetch the data from its source. I guess most of these information will not appear in the offering self-description, but will be stored in the connector, right ?

⚠️ We (marketplace developers) assumed that data sources can only be accessed through HTTP requests! Please tell us if it isn't the case.

Note that many of these parameters could be exposed on the consumer side as well, when requesting a transfer. For instance, the consumer could add a subpath to the request URL, as well as a body, headers and query parameters (potentially overwriting the one set by the provider). Please let us know if this should be the case.

And of course any other feedback you see fit.

[psotres]

This is related to EDC data plane framework (more info in 1 and 2).

In the short term you can stick to your HTTP assumption, but EDC data plane can support other technologies (3, 4, 5,...) and the required config parameters is technology dependant.

[xamcost]

Thank you for your feedback @psotres . Ok we will stick to HTTP then. Yet there are two things we would need to know, but most likely @telsaleh , @juanrasantana or INRIA can answer:

1. could we get an example of what payload to pass to the offering management component for offering creation/publication ? We tried to infer many of them based on the Sedimark ontology, but we couldn't see any fields in the defined objects such as Offering or AssetProvision corresponding to the request to perform to the HTTP data source endpoint, but maybe we are just missing it ?
2. will the marketplace only need to communicate with the offering management components to send it the data we collected from users about their offerings (and then offering management communicates with connector), or will it also need to send some info to the connector to identify the data source related to the offering ?

Thanks in advance!

[xamcost]

Closing since it is now covered by #8 and the fields to show in this form will be dictated by the ontology.