| Thanks Julia and Jim for your clarifications. Now it is clearer.
All the best On 27 Nov 2025, at 12:54, Pampus, Julia <julia.pampus@xxxxxxxxxxxxxxxxxx> wrote:
Dear José, If I may add to Jim’s answer. The DSP TransferRequestMessage (control plane) is not the data request actually initiating a data transmission (data plane). It is rather to be seen as a “Hey, let’s come back to our Agreement. I want to start sharing/consuming data. Is everything set up? Here is what I need/require”. Other DSP transfer messages may indicate a suspension, problem, or ACK about the end of a data transmission (on the data plane). Following this, the transfer format specifics are - indicated as format of the distribution in the catalog,
- part of the dataAddress in the TransferRequestMessage or TransferStartMessage (there you have the requested extensibility, see EndpointProperty [1]),
- and part of the data request on the data plane (not in scope of DSP, e.g., filter properties).
I hope this helps. Best regards, Julia From: dataspace-protocol-base-dev <dataspace-protocol-base-dev-bounces@xxxxxxxxxxx> On Behalf Of Jim Marino via dataspace-protocol-base-dev
Sent: Thursday, November 27, 2025 12:47 PM
To: José Cantera <jose.cantera@xxxxxxxx>
Cc: Jim Marino <jim.marino@xxxxxxxxx>; dataspace-protocol-base developer discussions <dataspace-protocol-base-dev@xxxxxxxxxxx>
Subject: Re: [dataspace-protocol-base-dev] Question: About extending the control plane to supply data filtering conditions The issue with the suggested design is twofold: - It conflates the concepts of a control plane and a data plane by associating properties that should only be scoped to the data plane with the control plane. Filtering is determined by the wire protocol used by the data plane, not the control plane. Please pay special attention to the distinction between the control plane and data plane.
- Adding additional properties to the TP message breaks interoperability and is prohibited by design in the DSP message schemas.
In other words, it is NOT good practice to extend DSP message types, and this is prohibited by the schemas. Hello, Thanks for the feedback. There are two questions here though: 1/ Is my example an appropriate usage of the Control Plane, and the response is probably not 2/ is it a good practice to extend Transfer Messages? And here my thought is, given that a Data Transfer Profile can be defined in terms of essentially a format, then a particular format may require extra properties to be incorporated to the transfer messages (that would be expressed in a custom Vocabulary) … However I am seeing that the schemas in the repo do not allow for additionalProperties …
The role of the TransferProcessRequest is to initiate a data transfer that happens out-of-band in the data plane. How the data is transferred - including filtering - should be done via the wire protocol of the data plane. For example, a REST API, subject filtering in a messaging system, etc. Extending a DSP message with custom properties is not interoperable and generally indicates a design issue. Dear all, This is a question on how to properly design a Data Transfer Profile and to gather experiences you may have had. So I am not proposing any new feature for the protocol at the moment. Do you think it could be a good idea to extend the `TransferRequestMessage` to specify upfront filtering conditions over the dataset you want to pull or push data? Example: I want all the entities in the dataset that match the filter and I request the transfer of only those. See below. Is this a proper usage of the Control Plane? Or should the filtering query only be specified through the data plane once the transfer has been set ? Thank you very much for your thoughts and feedback "@type": "TransferRequestMessage", "agreementId": "urn:uuid:27c4289f-36f1-4eb4-8fc9-8986be3d6e03", "consumerPid": "urn:uuid:48a5e643-8772-4bbb-a5c9-1f1318ced42d", "format": "Http-Pull-Query-Format", "@type": "EntityFiltering", "q": "destinationCountry == ES OR destinationCountry == PL"
|
