$ref resolution scope about jsonschema HOT 36 CLOSED

I have a good idea, involving setting the resolution scope when iter_errors is called, which would handle both cases. I'll code something up tomorrow.

from jsonschema.

What a mess. We can do a real service for implementors if we successfully break down all the cases here and write tests for them for the suite.

I see there is a new section in the draft 4 proposal that looks promising.

from jsonschema.

Yeah, I'm going to make up some more tests for this stuff too. One issue for adding to the test suite is that inline dereferencing is not required, which means the test schemas would actually have to be available at whatever uris we are using in the id fields for them to pass on validators only supporting canonical dereferencing.

@fge Speaking of this, if a validator is only supporting canonical dereferencing, and it gets a $ref equal to its base schema, is it still required to look it up on the network?

from jsonschema.

We could always give bin/jsonschema_suite a small webapp that serves up some schemas and put some tests for it in optional 😈

from jsonschema.

@gazpachoking what do you mean by "equal to its base schema"? Can you give an example?

from jsonschema.

I actually meant base uri. So for example in this schema:

{
    "id": "http://somewhere/schema.json",
    "properties": {
        "a": {"$ref": "#"}
    }
}

When the ref is encountered, would an implementation not supporting inline dereferencing pull it from http://somewhere/schema.json# ? Or use the copy it already has?

from jsonschema.

I'm guessing all implementations should use the copy they already have, otherwise fragment references in a schema with a blank base uri will not work.

from jsonschema.

We could always give bin/jsonschema_suite a small webapp that serves up some schemas and put some tests for it in optional

That might be a good idea. The tests wouldn't exactly be optional though... but running the webserver would be.

from jsonschema.

We could make optional tests that work for implementations with inline dereferencing without the webserver, and also worked for canonical dereferencing when the webserver was running.

from jsonschema.

@gazpachoking it depends on how you load the schema.

I guess most implementations will choose, when preloading schemas, to take the value of the top level id as the loading URI for that schema. But you may very well not choose to do so... So, in the end, there is no definitive answer, and it is implementation dependent.

In my case, I have a dedicated method for schema preloading, which will grab the value of id and take it as the loading URI if and only if it is an absolute JSON Reference (for instance, foo://bar#/baz is an absolute URI but not an absolute JSON Reference since its fragment is nonempty).

And of course there is the case when you dereference "x://y.z#" and have a schema which tells it is located at "a://b.c#"... id is "fun".

from jsonschema.

@fge Okay, I guess my remaining question is, in cases where the base uri is blank (no id, and schema was loaded locally,) should all implementations be able to use json pointer fragment references still?

from jsonschema.

If above is not the case, then all of our tests for ref in the suite are not technically required.

from jsonschema.

@gazpachoking well, if there is no "id" at all, the URI of the document is the URI you used to reference it. In this case, all "fragment only" refs resolve against this URI, and as such are located within the schema. So yes, these should be resolvable.

Note that there is no obligation at all that the loading URI of a schema be absolute. Which means of course that if you "get out" of this schema, you cannot reference it anymore.

from jsonschema.

@Julian Here's my latest idea for this problem: gazpachoking@e0ed587

The one case I know it will have a problem, is with a remote ref, which does not have an "id" in the schema. In this case we need to change the scope to be the URI that we looked up the remote schema from. Not sure how to handle that most cleanly yet.

from jsonschema.

Maybe we need to pass in the schema's uri as a keyword arg to iter_errors, which it will use instead of an id if present.

from jsonschema.

I'm sure you've done so, but before we make any decisions here, can we please collect a full comprehensive list of all the different behaviors/examples we'll need to handle, have that looked over by @fge and merged into the suite, and then we (I 😄) can see the entire scope of this?

from jsonschema.

I'm not deflecting your last two comments, but it's hard to reason about this without seeing all the behaviors.

from jsonschema.

Yeah, can do. The problem is that testing this behavior will definitely require a webserver, at least for implementations that don't support inline referencing (which we don't currently). The simplest example is already tested with my last addition to the suite, the one testing against the remote metaschema.

from jsonschema.

I see. So what do you think is the best way forward? Should we throw a simple webserver into the test suite and get cracking on that?

from jsonschema.

I think if we are to have any hope of comprehensive ref tests, a webserver is required. How exactly to write tests that use that I haven't fully thought through yet.

from jsonschema.

OK. Can you perhaps solicit comments from the json-schema guys by opening an issue about this on the suite? I'll try to educate myself a bit more.

from jsonschema.

Ehm, why a web server? Can't you just mock a socket or something? Python allows for that, right?

As to the list of possibilities, they are nothing short of infinite, unfortunately...

from jsonschema.

Yes Python does of course, but what we have in mind are tests that would depend on remote URIs resolving to actual schemas. If it was just Python I had to worry about I'd definitely do that by just mocking out the request, but we (me, you, us, the authors of the test suite) need to provide something that would make it easy for implementors in whatever language to run a test that expects to resolve a URI, and the easiest way at the moment would sound like using URIs like {"$ref" : http://localhost:1234/schema#foo} and providing people with a webserver that serves out that schema.

Do you have a better idea / see what we're getting at?

from jsonschema.

And I'm fine with infinite as long as the cases we have cover the common cases / whatever we can come up with now. Which certainly seems like more than what I came up with by just reading the draft3 spec.

from jsonschema.

@fge Yeah, currently we have no testing of anything involving the id keyword, it would at least be nice to have a few basic tests on how that should be handled. Implementing a solution is confusing enough, having more tests can only help the matter.

from jsonschema.

@Julian OK, I see where this is going. And HTTP is indeed the most commonly supported protocol among languages (even file has less support), so this looks like a good idea indeed. And you can also "mock" 404s, so this is all the more a good idea.

@gazpachoking that is true; as far as inline dereferencing is concerned though, this can be tested locally with, say:

{
    "$ref": "foo#",
    "x": {
        "id": "foo",
        "type": "string"
    }
}

Since the URI scope is relative to the schema URI, which can be anything, this should work if an implementation supports inline dereferencing. As a bonus, this also tests that implementations consider JSON references having no fragment or an empty one as exactly equal since they are (no fragment means the document URI, an empty fragment means the empty pointer at that URI and the empty pointer points to the document itself).

from jsonschema.

@fge Yeah inline referencing is a simpler case to test, we can certainly add some optional tests for that without any kind of server. But as that is optional to support, having some way for imlementors to test canonical referencing would also be good.

from jsonschema.

@fge Speaking of inline addressing, how is a validator supporting it supposed to determine if a key called "id" within the schema is actually an id keyword? Consider these examples:

Not id keyword:

{
    "dependencies": {
        "id": "otherthing"
    }
}

Actual id keyword:

{
    "nonkeyword": {
        "id": "realId"
    }
}

from jsonschema.

@gazpachoking that is a good question, one that I have already asked myself in the past as well.

And I cannot really give an accurate answer to that one... Only where they cannot be, such as in your first example.

Now, you have one more reason why I hate id with a burning passion :p

from jsonschema.

Yeah, I agree, it seems like unnecessary complication for little gain.

from jsonschema.

Gah. How about this situation

{
    "id": "base",
    "items": {
        "id": "anitem",
        "anyOf": [{"$ref": "#/x"}]
    },
    "properties": {
        "a": {"$ref": "#/items/anyOf/0"}
    },
    "x": {"type": "integer"}
}

If we are validating items, it seems pretty clear that the ref in items should resolve to 'anitem#/x', which would not be part of this document. However, if we are validating the "a" property of a dict, it seems the resolution scope for that would be changed to resolve to 'base#/x', which is in this document...

from jsonschema.

I guess we'd just chalk that up to a poorly written schema. It does seem ill conceived that the schematics of the id keyword allow for a ref to be in 2 different resolution scopes depending on where it is referenced from though.

from jsonschema.

@Julian As expected, the few tests I added already expose a problem in my latest implementation idea. I think it just needs a few lines tweaked though. I'll play around some more, probably add some more tests to the pull over at the suite as I progress.

from jsonschema.

Good, that's what I like to hear :P
On Feb 19, 2013 6:46 PM, "Chase Sterling" [email protected] wrote:

@Julian https://github.com/Julian As expected, the few tests I added
already expose a problem in my latest implementation idea. I think it just
needs a few lines tweaked though. I'll play around some more, probably add
some more tests to the pull over at the suite as I progress.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/66#issuecomment-13807415.

from jsonschema.

Fixed in #68 yes?

from jsonschema.

Yep.

from jsonschema.