Types not generated for GLTF 2.0 schema (expected a '/' in $ref)

[nick-ls]

Expected behavior

Types are correctly generated for this schema that passes jsonschema lint when the import_types! macro is used.

Actual behavior

The macro panics with this message: proc-macro panicked: expected a '/' in $ref: glTFProperty.schema.json.

Steps to reproduce:

1. Place this (somewhat) minimal JSON Schema in a folder where import_types! can find it
2. Use the import_types! macro within main.rs to attempt to generate types for the schema
3. Observe that it panics with the message proc-macro panicked: expected a '/' in $ref: glTFProperty.schema.json

---

The same panic occurs with the unmodified JSON Schemas both when the root schema (glTF.schema.json) is passed to import_types! (with each schema in the directory being named the same as its $id), as well as when they are bundled and the bundled schema is passed. The panic also occurs after applying jsonschema lint's suggested fixes to the individual files (none of the fixes were for syntactic errors). For the final linted, fixed, and bundled file, the story is no different.

[ahl]

This schema uses JSON Schema 2020-12--that's not causing any proximate issues since its not using any 2020-12 specific features, but it's still worth noting

The more acute issue is the references. Typify currently makes some invalid assumptions about the shape of references, in particular that each will be of the form #/$defs/xxx. Support for this is a slow work in progress.

We can work around this by updating the $refs with a script like this:

jq '
  walk(
    if type == "object"
       and has("$ref")
       and (."$ref" | test("^(#|https?://)") | not)
    then
      .["$ref"] = "#/$defs/" + .["$ref"]
    else
      .
    end
  )
'

This schema makes use of the $id field in a way that I haven't seen before. In particular, the top level schema effectively uses a relative URL (I guess that would be the initial base URI). And the subschemas register their own relative $ids. Per the spec:

The presence of "$id" in a subschema indicates that the subschema constitutes a distinct schema resource within a single schema document. Furthermore, in accordance with RFC 3986 section 5.1.2 regarding encapsulating entities, if an "$id" in a subschema is a relative URI-reference, the base URI for resolving that reference is the URI of the parent schema resource.

If no parent schema object explicitly identifies itself as a resource with "$id", the base URI is that of the entire document, as established by the steps given in the previous section.

Which is all to say that this schema looks perfectly valid... just atypical.

This also kicked over another error:

{
  "$ref": "#/$defs/Inner",
  "type": "object",
  "title": "Foo",
  "properties": {
    "extras": {}
  },
  "$defs": {
    "Inner": {
      "type": "object"
    }
  }
}

This schema causes typify to fail--I believe it's because we have failed to provide a name for a type we're generating.