Adds a preliminary IANA section with placeholders. #27
Conversation
spec/index.html
Outdated
| <!--p>Other specifications MAY create further structured subtypes | ||
| by using `+ld+json` as a suffix for a new base subtype, as in | ||
| `application/example+ld+json`. | ||
| Unless defined otherwise, such subtypes use the same | ||
| fragment identifier behavior as `application/ld+json`.</p--> |
There was a problem hiding this comment.
If we think this is the case, we need to file an issue and remove the commented text from the spec.
Otherwise, remove.
| <!--p>Other specifications MAY create further structured subtypes | |
| by using `+ld+json` as a suffix for a new base subtype, as in | |
| `application/example+ld+json`. | |
| Unless defined otherwise, such subtypes use the same | |
| fragment identifier behavior as `application/ld+json`.</p--> |
There was a problem hiding this comment.
I simply removed the section for now.
spec/index.html
Outdated
| This includes the ability to associate a file extension with a `profile` parameter.</p> | ||
| <p> | ||
| When used as a <a data-cite="RFC4288#section-4.3">media type parameter</a> [[RFC4288]] | ||
| in an <a data-cite="rfc7231#rfc.section.5.3.2">HTTP Accept header</a> [[RFC7231]], |
There was a problem hiding this comment.
| in an <a data-cite="rfc7231#rfc.section.5.3.2">HTTP Accept header</a> [[RFC7231]], | |
| in an <a data-cite="rfc9110#rfc.section.12.5.1">HTTP Accept header field</a> [[RFC9110]], |
Probably, we could simplify this section, eg.
When using this parameter in content negotiation (see Section 12.5 of RFC9110), its value MUST be
enclosed in double quotes...
Q: is the procedure above specific to the profile parameter or it is generally valid for all media type parameters? In case, I can double check.
There was a problem hiding this comment.
I believe it's generally true about parameter values.
| <dt>Optional parameters:</dt> | ||
| <dd> | ||
| <dl> | ||
| <dt><code>profile</code></dt> |
There was a problem hiding this comment.
Q: this section is very long. To ensure it is aligned between yaml+ld and json+ld we could probably just reference
the parameter from either the ld+json registration or the json-ld specification document which was used for the registration of ld+json. WDYT?
| <a data-cite="JSON-LD11##iana-considerations"> and additionally defines the following:</a> | ||
| </p> | ||
| <dl> | ||
| <dt><code>http://www.w3.org/ns/json-ld#extended</code></dt> |
There was a problem hiding this comment.
Should be http://www.w3.org/ns/yaml-ld#extended
There was a problem hiding this comment.
That wasn’t an accident, as this spec is under the json-led umbrella, but it is worth considering.
Fixes #14.
Fixes #25.
cc/ @anatoly-scherbakov @juusoautiosalo
Preview | Diff