Support URI Resolution Scope Alteration compatible with JSON Schema

[ippeiukai]

Thanks for the great library. I use json-refs in conjunction with angular-schema-form as suggested here: json-schema-form/angular-schema-form#118 (comment)

I'd like to suggest a new feature to enhance support of JSON Reference as it is used in JSON Schema.
JSON Schema extends JSON Reference with alteration of URI resolution scope by reserving "id" keyword for the purpose:
http://json-schema.org/latest/json-schema-core.html#anchor25

I would love to see this implemented as an option.
e.g. JsonRefs.withUriResolutionScopeAlteration({"idField":"id"}).resolveRefs(json, done)

I found URI Resolution Scope Alteration would also be useful for my own purpose when embedding nested resources.

[whitlockjc]

Thanks for the kind words and the feature request. What you seek is called inline dereferencing and I'll need to think about how best to support it. I already support URI resolution but not by id, by path. I'll get to this soon, although I cannot guarantee exactly when as my plate is pretty full right now.

[whitlockjc]

I'm not sure it's possible to handle this without some extra work. JSON References are not adhering to the JSON Reference or even JSON Pointer specifications. If you have a reference with an id in it, based on JSON References you're accessing a relative, external document. So to support this, I'd first have to check against all ids and then check against the relative location, or vice versa. Either way, this is a JSON Schema feature and not one specific to JSON References or JSON Pointers so I think I'm going to have to punt on this.

Feel free to continue the discussion and maybe we can come up with something.

[whitlockjc]

I'm not 100% against doing this. I'm reopening but no guarantee on when it will be done.

[brettz9]

id is still usable for determining base paths, even if inline referencing is not used (i.e., canonical referencing is still supposed to treat "id" in a special way)... Perhaps this ties into issue #76

[whitlockjc]

It's not related to #76. #76 is a short sided issue caused by testing relying on it. I'll fix that. As for inline referencing, I don't see anywhere in the JSON References specification where id is mentioned so without inline referencing support, I don't think id has any special meaning.

[brettz9]

See http://json-schema.org/latest/json-schema-core.html#rfc.section.7.2 where "id" is defined as altering resolution scope. Note also that as per 7.2.3, this is not only for inline dereferencing but also for canonical dereferencing.

[whitlockjc]

That's a JSON Schema construct, not a JSON Reference construct. Nowhere in the JSON Pointer or JSON Reference specifications do they mention JSON Schema. Since this request is for a JSON Schema specific feature, I wonder if it makes sense in this library. I'm not saying nothing can be done, I just need to think about it a little more.

[brettz9]

Oh, sorry... (You have to forgive me that the "brain fog" that comes with my chronic fatigue can sometimes cause me to overlook some very obvious things.)

[whitlockjc]

No, you're not in the wrong. I blame Swagger. :) Swagger is it's own thing with cherry picked parts of JSON Schema, JSON Pointers and JSON References sprinkled together. It's very confusing. I need to figure out what, if anything, I should do about it.

[brettz9]

Well, I should know better, as I'm not using Swagger myself, so no real reason in my case to confuse things there. Surprising JSON references doesn't have such an ID mechanism...

[whitlockjc]

My bad for assuming. Any who, don't sweat it. I just need to do a little more digging.