Complex relative $refs

[gaav....@gmail.com]

Hello there,

I'm trying to structure a JSON schema for complex messages. I'm using the python-jsonschema library, all schema's are draft 4.

I have 'decided' on the following structure:

.
├── actions
│   ├── create.json
│   └── modify.json
└── definitions
    ├── generic
    │   ├── address.json
    │   ├── email.json
    │   ├── integer-1024.json
    │   ├── integer-unlimited.json
    │   └── user.json
    └── object
        └── quota.json

I'm using $refs with URIs relative to the root. For instance, create.json will reference definitions/object/quota.json. So far, this works fine. The problem arises when quota.json would also $ref another json file. It seems that the relative path is then based on the path of quota.json. This means that a $ref to definitions/generic/address.json from definitions/object/quota.json will result in the path definitions/object/definitions/generic/address.json . This obviously will not work.

I've tried to find a solution to this problem, but none of Google, StackOverflow and "Understanding JSON Schema" seem to provide a solution.

Can someone advise on what to do or change? I'm trying to avoid a single huge JSON schema file (which most solutions seem to steer towards).

[Eric G]

../definitions/generic/address.json   ?

or stick all your definition schemas in a flat directory hierarchy and reference them from within other definition schemas simply like  "address.json"  ?

[Lee Dixon]

Hi, I have this same issue.  Did you ever find an answer?  Putting everything in a flat hierarchy essentially is saying that references in JSON schemas are broken.

[Nick Douma]

Hi,

On 27-04-16 16:33, Lee Dixon wrote:
> Hi, I have this same issue. Did you ever find an answer? Putting
> everything in a flat hierarchy essentially is saying that references in
> JSON schemas are broken.

Not JSON schema per se, but the Python implementation.

I eventually resolved this issue by writing a compiler, which loads all
externallay referenced schemas into the main schema. This avoids the
whole issue, because no external lookups have to be made.

Unfortunately, I'm not at liberty to provide you with the code, because
it's part of a closed source project.

Kind regards,

Nick Douma