Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Referencing other local JSON Schemas #63

Closed
marksto opened this issue Apr 11, 2019 · 5 comments

Comments

Projects
None yet
2 participants
@marksto
Copy link

commented Apr 11, 2019

I have strong doubts whether this is a bug or not, but it is definitely a nice-to-have feature which is foreseen by the JSON Schema specification.

What the specification states

The Schema References With "$ref" section states the following:

Schemas can be identified by any URI that has been given to them, including a JSON Pointer or their URI given directly by "$id". In all cases, dereferencing a "$ref" reference involves first resolving its value as a URI reference against the current base URI per RFC 3986.

As an example it provides the following simple case:

When an implementation encounters the reference to "other.json", it resolves this to <http://example.net/other.json>, which is not defined in this document. If a schema with that identifier has otherwise been supplied to the implementation, it can also be used automatically.

And this is how it works in the latest version of the Manifold, no offense here. 😄 We are able to reference the schema with the same base URI, i.e. on the same level in the filesystem's directory structure. It compiles and it runs smoothly.

At the same time, it is impossible to introduce any hierarchical structure on top of one's schemas, i.e. to use subdirectories and reference other schemas relatively in both directions: forth with "sub/other.json" and back with "../other.json".

But there are these "can be identified by any URI" and "In all cases <...> resolving its value as a URI reference against the current base URI" parts that make me believe that such a scenario is also considered possible, yet omitted in the current Manifold's implementation.

What the specification doesn't state yet

What causes my doubts is an associated cite reference:

What should implementations do when the referenced schema is not known? Are there circumstances in which automatic network dereferencing is allowed? A same origin policy? A user-configurable option? In the case of an evolving API described by Hyper-Schema, it is expected that new schemas will be added to the system dynamically, so placing an absolute requirement of pre-loading schema documents is not feasible.

While it is not feasible in the wild (a.k.a. World Wild Web), we are dealing with a special case of "static resources as Java Types" and it would seem that it doesn't matter much. However, there might be matters to discuss.

What everyone (including myself) definitely wants to be able to do is to work with such references without fuss in the Manifold's "dynamic mode".

Scenarios in scope

Test 1

Checks an ability to reference the "sub/other.json" schema from the current one.

Manifold is unable to compile such a schema in the current implementation:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project manifold-json-subschema-test: Compilation failure: Compilation failure:
[ERROR] /abc/res/Test1.java:[39,11] cannot find symbol
[ERROR] symbol:   class SubTest1
[ERROR] location: interface abc.res.Test1
[ERROR] /abc/res/Test1.java:[44,27] cannot find symbol
[ERROR] symbol:   class SubTest1
[ERROR] location: interface abc.res.Test1
[ERROR] /abc/res/Test1.java:[70,32] cannot find symbol
[ERROR] symbol:   class SubTest1
[ERROR] location: class abc.res.Test1.Builder
[ERROR] /abc/res/Test1.java:[82,27] cannot find symbol
[ERROR] symbol:   class SubTest1
[ERROR] location: class abc.res.Test1.Copier 

It also happens that Manifold's IntelliJ plugin is dealing fine (w/o "No such file or directory" error) with such a "$ref".

test-1

Test 2

Checks an ability to back-reference the "../other.json" schema from the current one.

⚠️ In case Test 1 succeeds, this one is also expected to pass according to the URI Relative Resolution rules.

Now it gives almost the same compilation error:

[ERROR] /abc/res/sub/SubTest2.java:[39,11] cannot find symbol
[ERROR] symbol:   class Test2
[ERROR] location: interface abc.res.sub.SubTest2
[ERROR] /abc/res/sub/SubTest2.java:[44,25] cannot find symbol
[ERROR] symbol:   class Test2
[ERROR] location: interface abc.res.sub.SubTest2
[ERROR] /abc/res/sub/SubTest2.java:[70,30] cannot find symbol
[ERROR] symbol:   class Test2
[ERROR] location: class abc.res.sub.SubTest2.Builder
[ERROR] /abc/res/sub/SubTest2.java:[82,25] cannot find symbol
[ERROR] symbol:   class Test2
[ERROR] location: class abc.res.sub.SubTest2.Copier

And is equally located by the IntelliJ plugin.

test-2


As always, test project is available here:
https://github.com/marksto/manifold-json-subschema-test

@rsmckinney rsmckinney added the bug label Apr 12, 2019

@rsmckinney

This comment has been minimized.

Copy link
Member

commented Apr 12, 2019

This is a relatively easy fix btw. Let me now if there is time pressure for this, I can fix it sooner.

@marksto

This comment has been minimized.

Copy link
Author

commented Apr 12, 2019

@rsmckinney, nope, there's no hurry. Hope that's really that easy as pluggin' in java.net.URL, doh!

rsmckinney added a commit that referenced this issue May 4, 2019

#63
- qualify class references with package name when use-site is in a different package
@rsmckinney

This comment has been minimized.

Copy link
Member

commented May 8, 2019

In progress

@rsmckinney

This comment has been minimized.

Copy link
Member

commented May 8, 2019

Fix available in release 0.65-alpha

@rsmckinney rsmckinney closed this May 8, 2019

@marksto

This comment has been minimized.

Copy link
Author

commented May 17, 2019

Superb, will check this out soon!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.