Remove confusing use of "absolute" URI.

[handrews]

The value of "$schema" is not required to be an absolute URI
as defined by RFC 3986 (with a scheme, but no fragment). It just
needs to be a URI and not a relative reference.

This is particularly important as the meta-schemas include
an empty fragment in their id URIs, which would be illegal if
RFC 3986 section 4.3 Absolute URIs were required.

[CroniD]

Hi @handrews ,

I'm sry, if this is the wrong place for questions, don't know where to issue this one, but it's related to your PR. So I hope it's okay.

Your change implies that the $schema keyword may contain uri's with fragments. So, in a hypothetical scenario, if someone wants to publish all his extended schemas in one (primary) resource (for whatever reason), one can refer them in $schema keyword by using e.g. "http://domain.com/extended/schemas#topic" (where "topic" identifies one of those extended schemas as secondary resource). That would be possible with your change, right? If so, how would the fragment part be handled in a validator implementation?

Thanks in advance. :)

[handrews]

@CroniD This is as good a place as any- if it turns into a larger conversation we can split it out.

What happened with this change is that I interpreted '"absolute" URI' as an RFC 3986 absolute (with scheme, no fragment) URI. So I changed the meta-schema to remove the trailing "#" (empty fragment). @awwright responded that he had not actually meant that, but just a URI (with a scheme) rather than a relative reference.

So this is not actually a "change" just a clarification of what was supposed to be there already.

You can definitely use a fragment in a schema, and I have used it like you said so I think that is fine. I'm glad that my reading of the "absolute" URI thing was incorrect.

[awwright]

@handrews What do you think about the "contains a scheme" language as used elsewhere?

[handrews]

@awwright I'd be fine with that. Feel free to open a new PR if you want or I'll resubmit this tomorrow.

[CroniD]

Hi @handrews ,

thanks for your answer. Any advise regarding the second question?

[handrews]

@CroniD by 2nd question I assume you mean this which I overlooked- sorry about that

If so, how would the fragment part be handled in a validator implementation?

The value of "$schema" is intended as an identifier and not necessarily a locator (so even if it is using a URL scheme rather than URN, it is not necessarily possible or advisable to download it). So in that sense, there's no handling- it's an opaque identifier and presumably you look it up in some sort of local stash of known schemas.

However, if it is used as a URL and downloaded (which in the system I'm working on is expected to be common), it's just like any other fragment usage. For identification purposes, it's still the whole thing. For access purposes, you download the document using the absolute URI (no fragment - the RFC 3986 meaning of 'absolute') and then apply the fragment to the resulting document. For application/schema+json this means either applying it as a JSON Pointer if the fragment begins with "/", or looking up a plain name fragment defined using id (probably now $id) somewhere in the document.

Does that answer the question?

[handrews]

@awwright updated with "scheme" language.

[CroniD]

@handrews It does. Thank you. :)