Draft 7 schema with an $id containing an empty fragment produces resolution errors for subresources #1064
Comments
philvarner
changed the title
|
I originally had something about pre-releases resolving, but this has either been fixed or I had the alpha versions in my local cache. |
|
Hi there, please minimize your example to some specific example that you believe is incorrect, as certainly on its own this isn't necessarily indicative of a bug (and yeah as you modified, there's no such thing as marking something as a pre-release, so presumably what happened has to do with your setup) |
Julian
added
Waiting for Author
|
Ok, here's the output just using jsonschema. If there is an additional parameter I need to set, I would not expect changes like this across minor versions. |
|
Thanks, but it's again quite a bit more helpful for you to minimize your example rather than pointing to a big instance and big schema.
Hard to say without diagnosing, which is why the minimized example would help. https://stackoverflow.com/help/minimal-reproducible-example has some notes (and specifically giving the minimal possible schema+instance which produces your issue is the most helpful bit in this case). Regardless though, that isn't a good assumption to make. If there's a bug in this library that means that it doesn't have correct behavior according to the specification, that is exactly the sort of thing that may get fixed in minor versions (or even patch releases), so there's some chance it's your schema which is invalid, worked before, and now doesn't because that behavior was fixed. I won't guess what's more likely though, we may as well just look at the minimal example and see. |
|
For reference, here's what an essentially minimized example looks like: from jsonschema import validate
instance = {}
schema = {
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "https://schemas.stacspec.org/v1.0.0/item-spec/json-schema/item.json#",
"allOf": [{"$ref": "#/definitions/core"}],
"definitions": {"core": {}}
}
validate(instance=instance, schema=schema)where essentially it looks like your issue has to do with your I'll have to re-read the draft 7 specification, if I recall correctly, having an empty fragment is technically allowed, though discouraged (and there's notes in successive drafts saying that future drafts will probably make this an error). You probably should consider removing it, though after reviewing the specs if it turns out this is indeed strictly speaking allowed even if discouraged, I'm happy to make a fix. |
Julian
changed the title
|
It is allowed in Draft7, and (as you can see in your example), the draft itself uses it in Now that we're aware of the issue, we'll likely remove the empty fragment in a future release, but we're stuck with it for now. |
This is discouraged by the spec, albeit still allowed. Future versions may fully make it an error, which is why it seems to make sense to make this JSON Schema-specific (rather than e.g. doing it as part of Resource.id) as some other spec may allow it and have different behavior to my current understanding. Refs: python-jsonschema/jsonschema#1064
This isn't necessarily 100% 'nice feeling', but early versions of JSON Schema used URIs with empty fragments as their $ids, and even though later versions don't, and future versions may even make this an error, a downstream library (including jsonschema) is likely to copy these $ids exactly as-is and expect the resource to be retrievable, despite the last commit making some of this behavior JSON Schema-specific. We may revisit this all later if/when it turns out to matter. Refs: python-jsonschema/jsonschema#1064
|
Fixed in referencing 0.25.3. |
Julian
removed
Needs Simplification
This is an issue with 4.18.0a1 and 4.18.0a2, but not an issue with 3.x and 4.17 (and presumably all pre 4.18 versions).
The following json file validates against the schema
https://schemas.stacspec.org/v1.0.0/item-spec/json-schema/item.jsonprior to 4.18.0a1:S1A_EW_GRDM_1SDH_20220101T230242_20220101T230351_041273_04E7D5_F22B.json.txt
I'm using jsonschema thorough the stac-validator package, so this is what the outputs are from.
Running:
With jsonschema=4.17:
with 4.18.0a2:
Additionally, it looks like these alpha releases where published to PyPI without the correct pre-release flag, so they're resolving for the constraint>=3.2.0that stac-validator has. It would be preferred for this not to be the case.The text was updated successfully, but these errors were encountered: