Relative paths between definition files are not resolved

[sven1103]

Dear all,

first: thanks a lot for this great library, which enables me to use JSON schema validation during QM procedures in data management for JSON-based metadata!

I am struggling with an java.net.MalformedURLException: no protocol exception for a complex schema, which I am unable to resolve.

Given the following example root schema to reproduce my findings:

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "$id": "https://myexample.org/example/example.schema.json",
    "type": "object",
    "properties": {
        "house": { "$ref": "definitions/buildings.json#/house" }
    }
}

Let's say that the definitions are in a separate file in a subdir of the root schema's location definitions.

{
    "house": {
        "type": "object",
        "properties": {
            "rooms": { 
                "type": "array",
                "items": { "$ref": "#/room" }
            }
        }
    },
    "room": {
        "type": "object",
        "properties": {
            "door" : { "$ref": "stuff.json#/door" }
        }
    }
}

And for the sake of modularity and structuring, the door property is defined in another json file:

{
    "door": {
        "type": "object",
        "properties": {
            "material": { "type": "string" }
        }
    }
}

Validating an example object (which should throw a validation error because material is not a String)

{
   "house": {
       "rooms": [ {
           "door": { "material": 1 }
       }]
   }
}

throws: Caused by: java.net.MalformedURLException: no protocol: stuff.json (Stack-trace: https://pastebin.com/rQip3Gmn).

I tried to set the default resolutions scope explicitly as well with the schema builder, but the issue remains.

So my question is: why is the relative path of buildings.json#/house resolved properly, but not stuff.json? Am I violating the JSON schema specification?

I am thankfully looking forward to any remarks/help!

Best, Sven

[erosb]

Helo @sven1103 , thanks for opening this issue.

As a quick fix you can set "$id": "https://myexample.org/example/definitions/buildings.json" in the building.json file. I hope it is not a blocker for you to use an absolute URL hard-coded in the schema file.

Later I will look into the problem in detail.

[sven1103]

Dear @erosb

thank you for your quick reply. I added the $id property in buildings.json, and indeed I get an ValidationException as expected!

Great!

I hope it is not a blocker for you to use an absolute URL hard-coded in the schema file.

Not a blocker no, but of course relative URIs give me some reusability advantage of the schema, if one wants to adapt the schema for local usage only, without or only restricted internet connection.

Feel free to ping me, if you have more questions about this issue.

[octavianN]

Hello,

I encountered a similar problem when I tried to validate UBL 2.2 JSON schemas.
You can download the schemas from here:
https://www.oasis-open.org/committees/document.php?document_id=64227

If you load "json-schema/maindoc/UBL-Order-2.2.json" a "FileNotFoundException" exception is thrown. One of the modules UBL-CommonBasicComponents-2.2.json is not resolved correctly.

I also have a SchemaClient, that resolves the current URL to the "baseURL". The base URL is the URL of the main schema "json-schema/maindoc/UBL-Order-2.2.json".

SchemaClient schemaClient = new SchemaClient() {
        @Override
        public InputStream get(String url) {
          try {
            URL resolvedURL = new URL(baseURL, url);
            return (InputStream) resolvedURL.getContent();
          } catch (IOException e) {
            throw new UncheckedIOException(e);
          }
        }
      };
SchemaLoader.load(schemaJson, schemaClient);

Best Regards,
Octavian

[erosb]

Hello both,

I fixed the bug during the weekend and it will be included in the next release.

[sven1103]

@erosb Great, thanks a lot for your quick response!

[erosb]

Hello, version 1.11.0 is out, including the fix. Thanks for the bugreport.

[sven1103]

great @erosb thanks a lot!