Allow using URN and not just URLs #166
Comments
|
related to #100 |
|
@flozano I agree that we need to support both. For now, most users are using external references as they want to share some comment schemas between the specifications of services. Eventually, users would like to refer to some common schemas. |
|
In our case, it's not so much about sharing with 3rd parties, but about our own private schemas. We have many schemas which use URNs that refer to a few well-known schemas. If we could use URI instead of URL it would be fixed. I could attempt to do a pull-request, but I'm afraid URL is scattered all over the code, so it'd be very big. |
|
@flozano Please give it a try. We have sufficient test cases to ensure nothing is going to break. |
|
@flozano Could you please provide several examples of URNs that are publicly accessible? Also, any documents or links that might help us to understand the requirement in your case. |
|
You can see one here: in this example, the ref refers to a URN inside the same document, but it could be externally defined. Basically I think schema validator should not dictate what references are and how they are fetched for everyone. By using URL you enforce the references to be URLs, by using URI you can let the "fetcher" implementator decide how to resolve those. |
|
Please note that, as per https://json-schema.org/understanding-json-schema/structuring.html, $ref and $id are URIs and not URLs |
|
For people (including me) who are confused about URL, URI, and URN, please check this link https://stackoverflow.com/questions/176264/what-is-the-difference-between-a-uri-a-url-and-a-urn I think we should support all of them as they do have a place in the JSON schema. |
|
I'm starting to understand what you're looking for. We already have a means for injecting a URLFetcher, but the main problem is combining the ids and $ref values together. If the ids and $refs are for a URN, then they probably just get concatenated (that's my guess). However, a URL component has some special rules (which are handled by the URL constructor). I could make the update and allow some sort of injectable fetcher for custom schemes. |
|
There only seems to be 7 files that need updated at first glance. It looks like the URI constructor and URI#resolve method do what we need. We just need to make some sort of URIFetcher that allows custom schemes to be fetched. By default, the current URLFetcher can be used for all of the URL schemes. |
|
I've got something almost done, but I'm having problems with combining ids and $refs. The URI#resolve method doesn't work as expected for some things and broke some of the tests. One of the failing unit tests had to do with the custom classpath: URI scheme. The id was 'classpath:/tests/relativeRefRemote.json' and the $ref was 'integer.json'. I would have expected that to be recognized as a relative path and to end up with 'classpath:/tests/integer.json'. However, the result was 'integer.json' as the combined URI. The only builtin Java tool I've found for combining these things correctly so far has been the URL constructor. Maybe we need to allow injectable behavior for combining pieces of URIs based on the scheme. We can use the URL constructor for the URL schemes (which would include our custom classpath scheme) and expect a custom 'combiner' for other URIs. |
|
wow that was fast. If you upload what you have I can try to help... as you know better the code-base, there's no point in me trying to duplicate the effort. I was still exploring how to do it. I agree using different strategies for URL-looking URIs and for non-URL-looking URIs should be doable. |
|
My computer's hard drive ended up dying on me right before I uploaded my
changes. I'm going to need a bit more time to get all of that sorted out.
I've got a solution all figured out. I just need to rewrite it.
…On Thu, Jun 20, 2019 at 8:06 AM Francisco A. Lozano < ***@***.***> wrote:
wow that was fast. If you upload what you have I can try to help... as you
know better the code-base, there's no point in me trying to duplicate the
effort. I was still exploring how to do it. I agree using different
strategies for URL-looking URIs and for non-URL-looking URIs should be
doable.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#166?email_source=notifications&email_token=AAWC3XBXKDH6P3GYZOFEF5DP3OMIJA5CNFSM4HY6IVB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYFWIHY#issuecomment-504063007>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAWC3XCKP5WNKDY7W7OZTHTP3OMIJANCNFSM4HY6IVBQ>
.
|
|
I think I got something worked out on a spare computer. I'm going to submit a pull request. |
|
@jawaff I am sorry to hear the hard drive problem. I have sent you an invite to join light-4j so that you can create a branch and constantly check in your code. I am doing the same although my hard drive is backing up daily. |
|
@stevehu Thanks for the invite. I've got a fork of this project. I could have easily checked in my changes to the fork, but I was still experimenting and didn't really want to yet. It's not a big deal. I've got everything rewritten and ready to review now. Hopefully you like my solution. |
1 similar comment
|
@stevehu Thanks for checking out my updates so quickly. I hope I didn't miss anything in my updates. |
|
I messed up a bit and still need to add in a URIFactory for the 'urn'
scheme, just so you know. I was still confused until I found a spec for the
structure of URNs. However, I don't think there's a standard way to fetch a
URN's file, so a URIFetcher will still need to be injected (I'm assuming
you already got that figured out).
…On Wed, Jun 26, 2019, 2:01 AM Francisco A. Lozano ***@***.***> wrote:
This covers all our scenarios, very little glue code was needed.
We're just ditched our own fork of the "everit" validator and already
enjoying this validator.
Thanks a lot @jawaff <https://github.com/jawaff> and @stevehu
<https://github.com/stevehu> !!!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#166?email_source=notifications&email_token=AAWC3XCZEF24C23SLEVERS3P4MV5BA5CNFSM4HY6IVB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYS3IAI#issuecomment-505787393>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAWC3XE7W6P6C3CY3C6BVC3P4MV5BANCNFSM4HY6IVBQ>
.
|
|
I'm glad I could help. I really like this project. It's simple and
organized well. I almost went with everit a while back, but I didn't like
how they used their own json parser instead of Jackson or Gson.
…On Wed, Jun 26, 2019, 2:01 AM Francisco A. Lozano ***@***.***> wrote:
This covers all our scenarios, very little glue code was needed.
We're just ditched our own fork of the "everit" validator and already
enjoying this validator.
Thanks a lot @jawaff <https://github.com/jawaff> and @stevehu
<https://github.com/stevehu> !!!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#166?email_source=notifications&email_token=AAWC3XCZEF24C23SLEVERS3P4MV5BA5CNFSM4HY6IVB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYS3IAI#issuecomment-505787393>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAWC3XE7W6P6C3CY3C6BVC3P4MV5BANCNFSM4HY6IVBQ>
.
|
|
Hello. I've been reading through various threads about supporting nested schemas and am still unable to tell if that is supported in networknt json-schema-validator. I have my schema defined locally in my project. When I write my definitions in my main schema file and reference them, everything works. But I really prefer to have my definitions in other files within the same directory. I cannot get my refs to those definitions to work though. I need to understand if I'm doing something wrong or if this capability is simply not supported by this library. If it IS supported, could you please provide a very basic example of referencing a definition in another, local file? Thanks. |
|
In the specification, local files are not supported. We do have some ways to support local files, but it is not recommended. |
(From #141)
Right now, if we understand correctly, references to external schemas are forced to be URLs.
We'd like to extend the validator to register some well-known URNs for some internal schemas, without publishing them in a valid URL, but we don't think it's possible in a clean way with current code-base, so if we want to use this library we need to replace those URNs to URLs in a pre-processing which shouldn't be required.
The text was updated successfully, but these errors were encountered: