Relative reference to parent folder in url

[bluecitylights]

I have an issue using a relative reference to the parent folder.
my schema is located in
<s3-url>/folder/myschema.json
myschema.json contains a "$ref" : "../someschema.json".
this one is located in
<s3-url>/someschema.json

when i call schema.validate() I get a 404 error. Using fiddler can see that manatee is trying to download:
<s3-url>/folder//someschema.json
Notice the double slash.

Note that VSCode is able to use my existing schema. I also tried to validate using another library NJsonSchema. which also just works.

I hope you can help me with this, because the manatee looks very promising.

[gregsdennis]

Thanks for reporting this. I'll set up a test for it.

[gregsdennis]

I've added a test that I think covers your case. Please take a look. The test passes, correctly processing both valid and invalid instances.

Test
Parent Schema
Child Schema

[bluecitylights]

Thank you Greg.

I notice one difference between my case and yours.
I have filled the "id"-property in the schema.

so /folder/myschema.json:
"id": "<s3-url>/folder/myschema.json"

[bluecitylights]

Gregg,

enclosed you will find code to reproduce the issue:

var baseUri = @"http://xxx.s3-website-us-east-1.amazonaws.com/";
			var uri = new Uri($"{baseUri}nmi-engine/myschema.json");
			var schema = JsonSchemaRegistry.Get(uri.ToString());
			using (var reader = File.OpenText(@"c:\projects\products\pynmi\schema\example\plankpi-request.json"))
			{
				var json = JsonValue.Parse(reader);
				var res = schema.Validate(json);
			}

[gregsdennis]

Thank you for that. I'm going to try to work up a simpler example; one that highlights the specific issue, like my test does.

[gregsdennis]

I've been able to set up a more direct example using my files hosted here on GH that reproduces the issue. If you need to, you can remove references to your data.

Next time, if you need to send me sensitive info, please feel free to email me or find me on Slack. You can find a link to the workspace at the top of the README for the repo.

[gregsdennis]

It looks like the issue is the inner ID of your main schema: /properties/targets. It should be #/properties/targets. This is a URI fragment that indicates a location within the current file ({baseUri}nmi-engine/myschema.json).

For reference, here are my schemas:

In {baseUri}Issue173/BaseSchema.json we have

{
	"$id": "{baseUri}Issue173/BaseSchema.json",
	"$schema": "http://json-schema.org/draft-07/schema#",
	"properties": {
			"localProp": {
				"$id" : "properties/localProp", 
				"type": "string"
			},
		"refProp": { "$ref": "../Issue173Child.json" }
	},
	"additionalProperties": false
}

In {baseUri}/Issue173Child.json we have

{
	"$id": "{baseUri}/Issue173Child.json",
	"$schema": "http://json-schema.org/draft-07/schema#",
	"type": "integer",
	"maximum": 10
}

Here's what's happening:

1. Your main schema has an ID of {baseUri}Issue173/BaseSchema.json. This means that {baseUri}Issue173/ becomes the working directory.
2. The subschema declares an ID of /properties/localProp. This changes the working directory to {baseUri}/Issue173/properties/ because it's rebasing the document path based on the current working directory.
3. Lastly, the reference location ../child.json is applied, which goes up a directory, returning us to {baseUri}/folder/child.json. Obviously, that file doesn't exist, so you get a 404.

But when we use a URI fragment in the subschema, the working directory doesn't change, so we actually go up to the parent folder as we intended.

[bluecitylights]

Gregg,

thanks for the clear explanation. I can confirm that this fixes the issue.

does this also mean that the validation in VSCode is not implemented according to the standard, since it was not complaining about this?

Richard

[gregsdennis]

Glad it fixed your problem. It's definitely a possibility that VSCode is doing it wrong.

@handrews, just for my sanity, can you verify my logic above, please?

[gregsdennis]

@bluecitylights Happily, this did lead me to a bug about downloading schemas from https links! I'll have a fix up soon.

[handrews]

@gregsdennis It's not clear to me what the significance of {baseUri} is supposed to be, but looking at:

The subschema declares an ID of /properties/localProp. This changes the working directory to {baseUri}/Issue173/properties/ because it's rebasing the document path based on the current working directory.

I think you added a leading / there, because in the schema it's properties/localProp. Without the leading / you are correct in the {baseUri}/Issue173/properties/ result. But with a leading slash, you would be replacing the whole path. At which point I can't tell the result without knowing {baseUri}

But assuming the leading slash was a typo, this looks correct.