Support for schema URLs

[RangerMauve]

I'm using tv4 for validation, and I like how it fully supports referencing schemas by URIs as per the spec. Would you be up for supporting the addSchema function from tv4?

Or is this actually supported somehow and I didn't notice?

[alank64]

Hi RangerMauve,

I'm not quite sure I understand, maybe I read too quick but the goal of json-schema-filter was to filter only, not validate, that is validation should have been applied by what ever your flavour is. This allows json-schema-filter to be fast, and flexible in that any form of validation can be used, and applied while storing documents so that the filtering after is assumed to be valid and a step to avoid at this stage. Does this answer relate to your question? If not please explain in more detail.

[RangerMauve]

What I mean, is the case where your entire schema isn't defined in that particular JSON object that's being filtered. For instance, I have a schema for Person and it's located at example.com/schemas/person.json, and a Person has a Location. Now, the schema for Location is defined within example.com/schemas/location.json, and my Person schema has a part that looks something like:

{
"id": "http://example.com/schemas/person.json",
"type": "object",
  "properties": {
    "location": {
      "$ref": "location.json"
    }
  }
}

The behaviour of this would be to resolve the key under $ref as a URL relative to the id at the top, and fetch the schema via HTTP. In this case, it should resolve to http://example.com/schemas/location.json which would be what's used for validating the location property of Person. In the case of tv4, you can pre-supply schemas for the URLs so that you can just use them directly from memory.

[RangerMauve]

I guess a better title would be to request support for $ref in general.

[RangerMauve]

Something like deref would help with that. Or would you recommend that people pre-process their schemas into one full blob and inline any $ref pointers the the actual schema before passing it through this module?

[alank64]

Ah, I see where you are going, and I have questioned this as well, in addition your last point was how I envision it, you would first resolve all of your schema prior, store it or cache it, and then apply json-schema-filter. The goal for this npm is mostly to be able to filter out certain properties on the fly (each request/response), so that parts of a document, say internal information, or admin info, is extracted from the full document based on various json-schema definitions. I know it's somewhat of a specific use case, and in fact I thought it was a little too limited, but after publishing it, unless I'm mistaken, it appears to be more popular a use-case then I initially thought.

As I tell everyone, they are more then welcome to fork and implement their own validation, in our case we pre-validate, pre-resolve and store the schema per user group, on a request we pull the entire document (with some caching to reduce reads) and then filter it with json-schema-filter, this avoids validation and resolutions for speed.

That said, I probably should explain in the documentation that my focus for json-schema-filter is mostly that of response handling, i.e.: fetching and returning a document portions based on a json-schema (thus the "-filter" in the name), rather then the storage of user data, which is where I then to focus on the validation process taking place. Just a question of speed really!

[RangerMauve]

Yeah, I totally understand where you're coming from and I totally agree with your use case. I think it'd be nice if you had something in the readme telling people that they should consider pre-resolving all the refs in their schemas before using it with the library, then.