Resolvement Error in json schemas

[arnoweiss]

At least the following URI, my resolver wasn't able to find the relevant object. From the browser, it just redirects to this repo.

https://w3id.org/dspace/schemas/2024/1/contract-schema.json#/definitions/Offer

[sebbader-sap]

I think it's due to these lines from https://github.com/International-Data-Spaces-Association/w3id.org/blob/e25221b07186a8349ce7a242923f78c44efaa5c5/dspace/.htaccess#L20

## Redirect JSON Schemas
RewriteRule ^([0-9]+)/([0-9]+)/(catalog|negotiation|transfer)/([\w.-]+schema.json) https://international-data-spaces-association.github.io/ids-specification/$1-$2/$3/message/schema/$4 [R=302,L,QSA]
RewriteRule ^([0-9]+)/([0-9]+)/common/([\w.-]+schema.json) https://international-data-spaces-association.github.io/ids-specification/$1-$2/common/schema/$3 [R=302,L,QSA]

There is no "(catalog|negotiation|transfer)" in the stated link...

Proposal:

## Redirect JSON Schemas
RewriteRule ^([0-9]+)/([0-9]+)/contract-schema.json https://raw.githubusercontent.com/International-Data-Spaces-Association/ids-specification/main/releases/$1-$2/negotiation/message/schema/contract-schema.json [R=302,L,QSA]
RewriteRule ^([0-9]+)/([0-9]+)/(catalog|negotiation|transfer)/([\w.-]+schema.json) https://international-data-spaces-association.github.io/ids-specification/$1-$2/$3/message/schema/$4 [R=302,L,QSA]
RewriteRule ^([0-9]+)/([0-9]+)/common/([\w.-]+schema.json) https://international-data-spaces-association.github.io/ids-specification/$1-$2/common/schema/$3 [R=302,L,QSA]

BUT: There are more references in the schemas, not only to contract-schema.json, e.g.: https://github.com/International-Data-Spaces-Association/ids-specification/blob/63e5a401192336177f1d547ebd1f8e8f6f129269/releases/2024-1/catalog/message/schema/catalog-schema.json#L16

[sebbader-sap]

@mkollenstart I obviously had a wrong idea where the released schemas would be located. With this in mind, I see no other choice then preparing a hotfix and changing the refs from https://w3id.org/dspace/schemas/2024/1/negotiation/contract-schema.json#/definitions/Offer to https://w3id.org/dspace/2024/1/negotiation/contract-schema.json#/definitions/Offer What do you think?

[sebbader-sap]

@ssteinbuss we have prepared a quick fix, also changing the schema files under release/2024-1. Is this the right procedure or do we need to have an own bugfix folder, e.g., release/2024-1-bugfix (which will break a lot of other things, e.g., w3id etc.)

[sebbader-sap]

Independent of the release/2024-1 vs. release/2024-1-bugfix topic, we propose to create an new Github Release for this fix under https://github.com/International-Data-Spaces-Association/ids-specification/releases and leave the "old" one as-is.

[ssteinbuss]

I would propose:

• use the release folder 2024-1 and not create another release folder, as we are fixing this specific version
• create a new a new GitHub release and tag 2024-1-update1 or 2024-1-bugfix1. We keep the initial release then, but make the current version work for everyone.

I could create the release later today and provide information on the changes in the release notes.

[juliapampus]

@ssteinbuss When we touch the 2024-1, we cannot create a new git tag. This would lead to inconsistencies as tag = version = release folder. We could update the existing tag pointing to the new commit. Or create a new tag/version/folder with a consistent naming.

[ssteinbuss]

@juliapampus, ok, maybe my approach would have been too lighthearted in the end.

so I see 2 options:

• Commit into main and update the release folder 2024-1
• Update the tag 2024-1 to the latest commit
• update the release notes in GitHub with the new tag

OR

• commit into main and create a new release folder 2024-2 or 2024-1-bugfix or 2024-1-update1
• update the w3id redirects
• Create a new tag according to the name of the release folder
• issuing a new release

The question is now, do we talk about a fix or a change of the specification? We have a definition for this:

1. No changes to text content These changes include fixing broken links, style sheets or invalid markup.
2. Corrections that do not affect conformance Changes that reasonable implementers would not interpret as changing architectural or interoperability requirements or their implementation. Changes which resolve ambiguities in the specification are considered to change (by clarification) the implementation requirements and do not fall into this class. Examples of changes in this class include correcting non-normative code examples where the code clearly conflicts with normative requirements, clarifying informative use cases or other non-normative text, fixing typos or grammatical errors where the change does not change implementation requirements. If there is any doubt or dissent as to whether requirements are changed, such changes do not fall into this class.
3. Corrections that do not add new features These changes may affect conformance to the specification. A change that affects conformance is one that: makes conforming data, processors, or other conforming agents become non-conforming according to the new version, or makes non-conforming data, processors, or other agents become conforming, or clears up an ambiguity or under-specified part of the specification in such a way that data, a processor, or an agent whose conformance was once unclear becomes clearly either conforming or non-conforming.
4. New features Changes that add a new functionality, element, etc.

From my perspective this update is class 1 change and therefore can be conducted as version 2024-1, i.e. we will update the release folder and update the tag accordingly.