International-Data-Spaces-Association / ids-specification

The Dataspace Protocol is a set of specifications designed to facilitate interoperable data sharing between entities governed by usage control and based on Web technologies. These specifications define the schemas and protocols required for entities to publish data, negotiate Agreements, and access data in a data space
https://docs.internationaldataspaces.org/dataspace-protocol/
Apache License 2.0
26 stars 14 forks source link

Issues in JSON-Schema Definition #232

Open schoenenberg opened 4 months ago

schoenenberg commented 4 months ago

Hi,

I am currently going in detail through JSON-Schema Definitions and I found some inconsistencies on these definitions. I am not sure how these were created - manually or generated. Please triage them and if necessary fix them:

I will extend the list when I find more inconsistencies.

sebbader-sap commented 4 months ago

Great observations, I already prepared a fix for the first and third one.

RightOperand is not defined on purpose, as it can appear in many ways in JSON. If you can provide a pattern, very much appreciated!

The construct for Offer is also on purpose, due to the fact that we need to express that target is forbidden in most cases (everytime the schema validation goes through the Offer path) but not always (when coming through MessageOffer directly).

sebbader-sap commented 4 months ago

Let's use #236 to derive a solution.

schoenenberg commented 4 months ago

The construct for Offer is also on purpose, due to the fact that we need to express that target is forbidden in most cases (everytime the schema validation goes through the Offer path) but not always (when coming through MessageOffer directly).

@sebbader-sap I cannot completely follow what you are describing. But from what I understood you are referring with target to the Agreement.odrl:target, which is three references away. To be honest I think this is a way to complex data structure. Just imagine how somebody should implement it. You need separate classes/structs anyway, otherwise you are not able to implement a data structure, which in one case has a required attribute and in another case it is not required. A specs purpose is to be implemented, therefore it should strive for simplicity and not complexity. I would suggest to refactor this, I can make a suggestion but I need some guidance what else depends on it and needs to change accordingly.

Actually I was referring with the fourth issue to the fact, that this Json-Schema definitions-part is a key-value map and the key in this case is #/definitions/Offer instead of Offer.

sebbader-sap commented 4 months ago

the key in this case is #/definitions/Offer instead of Offer.

I see, this is of course a correct finding but already merged, see https://github.com/International-Data-Spaces-Association/ids-specification/blob/36960607a67793e3fc5089655102ac6d5b9b5445/negotiation/message/schema/contract-schema.json#L105

sebbader-sap commented 4 months ago

We need to continue this discussion as soon as the Eclipse Project has been established. As the 2024-1 release in this repo is nearly done, any further corrections / extensions need to happen in the new project.

schoenenberg commented 3 months ago

@sebbader-sap What is the status on this? I need these reported issues to be fixed or clarified. Otherwise I am partly blocked and cannot further review it..

Please also add the bug label to this issue, so that it gets better visibility..

sebbader-sap commented 3 months ago

@schoenenberg the problem is the current situation between the work inside IDSA (past) and Eclipse (future). Therefore, the general activity here is quite low. It will get better as soon as the new setup has been established.

sebbader-sap commented 3 months ago

Adding another yet one:

sebbader-sap commented 1 week ago

AbstractPolicyRule does not contain odrl:target:

The clause with not(required) didn't really work out as intended, therefore, this line has been deleted.

sebbader-sap commented 1 week ago

Open topics for the Eclipse Dataspace Group:

  1. Schema definition of the RightOperand
  2. Decide on odrl:prohibition - is it needed? If so, how shall it be modelled?

@ssteinbuss please move these topics to the new repo. Apart of that, I regard the findings of this issue as solved as I also, for now, do not see a need to change the timestamp format.