We had the need to include both instance data and a JSON schema in our payloads. I should mention we were using JSON Schema draft 7
They look something like this:
```json
{
"item": {},
"schema": {}
}
```
The `schema` always describes `item`. Within the `schema` we often use `definitions`. The issue was how would we reference a definition? At draft 7 there didn't appear to be a good solution. We didn't use JSON paths because it wasn't clear which path is correct? `#/schema/definitions/address` or `#/definitions/address` for example? The latter being correct when the schema is viewed outside of the enclosing object. But the former being correct within the context of the payload. We decided to use what I think might be called "anchors". Something like `#address`.
So a payload might look like
```json
{
"item": {
"address": "some string"
},
"schema": {
"definitions": {
"address": {
"$id": "#address",
"type": "string"
}
},
"type": "object",
"properties": {
"address": {
"$ref": "#address"
}
}
}
}
```
The issue comes up when we embed something like this in an `example` in an OpenAPI spec. Each `$ref` gives an error stating that it's value must begin with `#/`.
Another issue that comes up is that some of our payloads contain schemas that just say `"type": "array"` but have no `items` field. This is also highlighted as an error. But it's not an error in our spec. I'm not even sure JSON Schema requires `item`. But regardless we couldn't include it if we wanted as the software we are reporting examples for is fixed at the moment.
Is it not a defect that Swagger is running these OpenAPI validation rules on examples or example or default? I would think that within an example any legal JSON should be allowed as it's not part of the spec. It's a "JSON Literal" and especially if it's taken directly from a real work service, it should not trigger any errors in OpenAPI validation.
