Schema URL (e.g. https://id.uvci.eu/DCC.schema.json) redirects to 404

[daniel-eder]

Description

It seems the redirect for https://id.uvci.eu/* was changed to point to https://raw.githubusercontent.com/ehn-digital-green-development/ehn-dgc-schema/release/*.

As a result, the URLs used in DCC.schema.json are no longer valid, instead redirecting to a 404 error page, such as https://id.uvci.eu/DCC.schema.json, thus loading the schema and sub-schemata via HTTP no longer works.

Expected Behaviour

The URLs, as found in the schema files, should redirect to the matching json file.

[dirkx]

So the versioned URLs seem fine.

But the unversioned ones are are not. Were would you like these to go ?

[jschlyter]

@dirkx, one way to fix this for now is to ensure that default resolution ends up at the main branch.

[dirkx]

Jacabs solution as stopgap in place.

@daniel-eder @SchulzeStTSI is that a pragmatic solution for now ? And we figure out how you folks want to work versioned after this ?

[daniel-eder]

@dirkx thanks for implementing the stop-gap! I just talked @SchulzeStTSI, we'd prefer to link to 1.0.1 for the unversioned url (to avoid unexpected issues if there are future changes in main), and if possible release a new schema version 1.2.x that implements versioned URLs, and use only versioned URLs going forward. Could this be done?

[jschlyter]

I would claim that the unversioned URLs are reserved for v1 och the schema and that all changes are backwards compatible. Depending on how you look at things, that may not be true.

[dirkx]

Ok - will update the stopgap.

Obviously - ultimately you'll need to control this on the test size - i.e. reference specific versioned files.

[dirkx]

'not be true' -- I looked at some of the code used to handle this - and it is not exactly "Postels Law Complaint (TM)" - i.e. very very brittle. So perhaps easier for now to solve on 'this' side of the fence.

[miguelzapaton]

Second time here in less than two weeks that a program is reported to stop working due to a DCC JSON Schema not found error (404).

A good moment to point out that a JSON Schema (2020-12) NOT EVEN NEEDS to be downloadable from an URL specified in the "$id" property:

http://json-schema.org/draft/2020-12/json-schema-core.html#rfc.section.8.2.1

Implementations should better use local copies of schemas and therefore implement some kind of caching mechanism. This would also make them resilient for temporary network outages (-> "offline use").

@gabywh Probably another point for the FAQ?

[gabywh]

Second time here in less than two weeks that a program is reported to stop working due to a DCC JSON Schema not found error (404).

A good moment to point out that a JSON Schema (2020-12) NOT EVEN NEEDS to be downloadable from an URL specified in the "$id" property:

http://json-schema.org/draft/2020-12/json-schema-core.html#rfc.section.8.2.1

Indeed. So as this is already defined in the JSON schema core, I wouldn't expect to have to re-iterate that here.

Implementations should better use local copies of schemas and therefore implement some kind of caching mechanism.

In one possible approach, yes.

This would also make them resilient for temporary network outages (-> "offline use").

local caching: yes always good against e.g. network outages, just that the local cache needs to be well-managed wrt to changes in the original source (coherency)

@gabywh Probably another point for the FAQ?

+1 will do.

That said, I think there is a reasonable expectation of being able to get the schema files from a known good location - which would "most obviously" be the URI (URL?) in the DCC Schema, despite what the JSON standard actually states.

[gabywh]

https://github.com/ehn-digital-green-development/ehn-dgc-schema/wiki/FAQ#schema-location