Fix: #37. x-jsonld keywords.

[ioggstream]

This PR

• adds x-jsonld-type and x-jsonld-context Extensions to OAS 3.0
• these extensions are used to attach semantic information to OpenAPI 3.0 Schema Objects.
• fix Extension registry: x-jsonld-type and x-jsonld-object #37

Notes

• I successfully built the pages on docker.

[ioggstream]

As requested by @karenetheridge use openapi 3.2.0

[handrews]

I don't understand what's going on here. Are these just to work around the restriction on non-x- prefixed properties in OAS 3.0? If so, why does the example show openapi: 3.2 when you can just use @type and @context directly in OAS 3.1+ Schema Objects?

[ioggstream]

I don't understand what's going on here.
Are these just to work around the restriction on non-x- prefixed properties in OAS 3.0?

Those properties should be available at least for OAS3.0.

If so, why does the example show openapi: 3.2

Since these keyword should be available from OAS3.0+, I think they could be used even with OAS3.2. Reading the spec, I understand it is ok to do so.

when you can just use @type and @context directly in OAS 3.1+ Schema Objects?

Using @type and @context would just make a valid application/openapi+yaml file an invalid application/ld+yaml file ;)
I strongly advise against using @ in OAS/Schema files, since JSON-LD is widely used for data exchanges.

[handrews]

@ioggstream sorry for the delay in replying. My first reply was when I'd just woken up and I overlooked the reference to the I-D in the issue (if I even clicked through to the issue, which I might not have). I will read and respond properly as soon as I get a chance.

[handrews]

Sorry for the delay in getting back to this! No real concerns, but I do have a question about scope.

[handrews]

Based on your I-D, I see that this is primarily JSON Schema-oriented. But there are many API constructs where the description is spread across other types of Objects as well.

For example, while you might think of your form-encoded query string as one piece of data to model, it's actually split up over numerous Parameter Objects and Schema Objects.

Will restricting this to Schema Objects actually allow solving all of the semantic description use cases for an API?