Closed ioggstream closed 1 year ago
Not clear whether figure 3 in section 3.4 should be moved to Appendix A. Or some figure in appendix A should be moved to section 3.4, e.g., One interoperability issue, i.e., mapping keys that are not strings is clearly related to appendix A.1
I think the current place for this figure is appropriate. Non-string mapping keys are a cause of interoperability issues with JSON as well as pathlike fragment identifiers. However, the interoperability issues are not the exact same set for the two. For instance, with a YAML document that contains just the first part of the example:
non-json-keys:
0: a number
The a number
value is addressable as #/non-json-keys/0
, but the JSON representation of the same document:
{
"non-json-keys":
{ "0": "a number" }
}
explicitly casts the 0
as a string, rather than allowing for it to be parsed as a number by a YAML schema that supports such.
@ioggstream The current registration process says that a contact is a "person". https://www.rfc-editor.org/rfc/rfc6838.html#section-6.2 However, looking at the current registry https://www.iana.org/assignments/media-type-structured-suffix/media-type-structured-suffix.xhtml there appears to be a range of different entries that do not meet the definition of a person. The proposal in the current YAML draft seems aligned with other registrations, and so I see no reason to change it.
While this document is based on a given YAML version [YAML], the media type registration does not imply a specific version. This allows content negotiation of version-independent YAML resources.
This paragraph confused me when I read it the first couple of times. Would it be simpler to simply say:
This [YAML] media type registration is independent of YAML version. This allows content negotiation of version-independent YAML resources.
Closed via #76
Opsdir review
The request came from the media type mailing list. They provided a reference to the the SVG media type registration that places this information under the Additional information. The related issue is here.
We used the same wording from the +xml SSS registration.
Agree with @darrelmiller as no-change. See https://github.com/ietf-wg-httpapi/mediatypes/issues/79#issuecomment-1509262222
This point was discussed with the YAML community, and there is not an easy solution since a YAML resource could theoretically contain different YAML documents each with its own version (see the example below: we didn't add it to the document to avoid fostering this kind of practice). The current wording tries to keep things simple while warning implementers of possible issues.
We propose the following edit in #86
Foreword: a "YAML stream" is just the formal name of a YAML resource, that can contain one or more documents separated by
---
.The current YAML specifications (and thus, implementations) consider different documents in a stream as independent. Since during the editorial work there were some doubts on the correct behavior, we decided to clarify this in the Interoperability Considerations.
While the I-D does not specify "how" to signal an error, just that raising an error is an interoperable behavior. We explicitly avoid using normative clauses here, and used "ought" instead. Do you see any drawbacks in this?
See @eemeli 's comment. I agree with it. https://github.com/ietf-wg-httpapi/mediatypes/issues/79#issuecomment-1506517453
Already fixed.