RefPointerResolution: can't get through

[KtorZ]

Hi, I am really trying my best, but I can't get it to work and the errors are rather harebrained to me... A bit of context, I am trying to use hjsonschema to validate a Json schema using the official Swagger meta-schema (https://raw.githubusercontent.com/OAI/OpenAPI-Specification/master/schemas/v2.0/schema.json) which is itself derived from the official json meta-schema draft04.

main :: IO ()
main = do
    bytes <- unsafeDecodeFileStrict "swagger-meta.json"
    let (Success meta) = (\s -> SchemaWithURI s Nothing) <$> fromJSON bytes
    Right uriMap <- referencesViaHTTP meta
    let (Right validator) = checkSchema uriMap meta
    unsafeDecodeFileStrict "swagger.json" >>= print . validator
  where
    unsafeDecodeFileStrict :: String -> IO Value
    unsafeDecodeFileStrict file = do
        Just bytes <- decodeStrict <$> BS.readFile file
        return bytes

-- [FailurePropertiesRelated (PropertiesRelatedInvalid {_prInvalidProperties = fromList
-- [("swagger",[]),("host",[]),("info",[FailureRef (RefPointerResolution (SubschemaDecodingError 
-- "expected Schema, encountered String"))]),("definitions",[FailureRef (RefPointerResolution
-- (SubschemaDecodingError "expected Schema, encountered String"))]),("paths",[FailureRef 
-- (RefPointerResolution (SubschemaDecodingError "expected Schema, encountered String"))])], 
-- _prInvalidPattern = fromList [], _prInvalidAdditional = Nothing})]

From there, I've tried many things including inlining all references to json-schema.org in the meta swagger schema, which will give me new errors, ultimately referring to a RefPointerResolution error. The issue seems to come mostly from the meta schema (which I highly doubt would be incorrect since it can be used in different online tools without any issues and, because a lot of people already rely on it in different libraries).

For instance, if I try to validate the minimal input schema I can have:

{
    "swagger": "2.0",
    "paths": {},
    "info": {
        "title": "",
        "version": ""
    }
}

The library gives me:

-- [FailurePropertiesRelated (PropertiesRelatedInvalid {_prInvalidProperties = fromList [("swagger",
-- []),("info",[FailureRef (RefPointerResolution (SubschemaDecodingError "expected Schema,
-- encountered String"))]),("paths",[FailureRef (RefPointerResolution (SubschemaDecodingError 
-- "expected Schema, encountered String"))])], _prInvalidPattern = fromList [], _prInvalidAdditional = 
-- Nothing})]

Yet, validating the meta schema with checkSchema doesn't trigger any error.

Am I doing something wrong? Thanks a lot for the help.

[seagreen]

Thanks for the report.

Will you let me know if this branch fixes the problem? https://github.com/seagreen/hjsonschema/tree/fragment-resolution-fix

[KtorZ]

Some progress indeed (thanks!), but still not there unfortunately :(

[ FailurePropertiesRelated (PropertiesRelatedInvalid {_prInvalidProperties = fromList 
  [ ("swagger",[])
  , ("host",[])
  , ("info",[])
  , ("definitions", [FailureRef (RefInvalid "#/definitions/definitions" (...))])
  -- ...
  ]
]

From my past experimentations with the library, it seems that some words are given special meaning sometimes in places they shouldn't. For instance, having a definition named enum will fail to resolve but calling it someEnum would resolve as expected. While enum has indeed a meaning in the draft04 when specified as a property of a type object, I believe it shouldn't have any special treatment when used outside of this context. Maybe something similar is happening with definitions, could it be?

[seagreen]

I think your analysis is almost certainly right.

Unfortunately, trying to figure out what is and isn't a subschema within a document is tricky. For instance, #/definitions won't usually be a schema -- unless another schema in the document is {"$ref": "#/definitions"} and in that context it would be.

Can you provide the schema and data .json files that lead to your latest error? That may give me a clue to what we can do better.

[KtorZ]

Hey, thanks for the help you're providing on that (I hope we can get through it ^.^).

To reproduce the error described above (on the branch you just mentioned), the following schema is enough:

{
    "swagger": "2.0",
    "paths": {},
    "info": {
        "title": "",
        "version": ""
    },
    "definitions": {
      "Resource": {
        "type": "object"
      }
    }
}

validating this against the OpenAPI / Swagger 2 Meta-schema fails unexpectedly :(

[seagreen]

Sorry for the delayed response on this. Unfortunately I don't have the time or interest to maintain this any more (and the code is so questionable I hope whoever takes up JSON Schema in Haskell next starts afresh with a new codebase) so I've deprecated this library.

I did go ahead and release the first fix we worked out as part of 1.9.0.