Change:
by removing the section, and marking it and as deprecated aliases of . For use cases presenting YAML content as plain text, the media type is more appropriate.
Currently the spec supports fragment identifier based on "named anchors", e.g. references . Today alias nodes syntax is , but in the future alias nodes could support "pathlike" expressions, e.g. . Can "named anchors" fragment identifiers be extended in the future in a backward compatible way to suppot "alias nodes" syntax? Consider the following examples is a valid character for a named anchor, using as a pathlike separator might be non-trivial. Currently many YAML parser do only support though, so future YAML spec might restrict the syntax of named anchors keys might contain non-string characters (e.g. vs ). We need to know how pathlike elements are serialized, to identify a human-readable encoding (e.g. JSON Pointer) another example. A non human-readable encoding such as base64url would solve the issue, since we could just decode the string. This could be supported when pathlike are messy, e.g.
Feedback from NAME Maybe we could use something like
The easiest solution might be to initially restrict valid characters in the fragment identifier to . This would mean that while not all anchors are addressable, most would be. It would also allow relatively easy extension e.g. by making invalid as an fragment identifier, and therefore usable by a schema that extends it. Not sure how to express it, but it might be good to still reserve for future use by later YAML versions?
Or you could do the inverse and just keep = for application-specific fragment identifier schemes. BTW, why don't you include JSON pointer (RFC6901) in the standard set? That is quite useful for the majority of YAML applications (certainly the JSON compatible ones).
WRT sub-mediatypes like openapi and jsonschema, we are discussing in URL jsonschema supports two fragment identifiers: JSON Pointers and . Plain names are just strings, e.g. "foo". We could ask NAME if there is some space to tweak the usage of plain names as fragment identifiers. I think it would be useful, but I think it's YAML community choice (aka NAME ). Probably the easiest way to do it is: use JSONPointers if starts with use alias names if starts with This will allow further space for subtypes, eg. use jsonpath if starts with I am not sure that using unstructured strings as fragment identifiers is an interoperable choice at all. What do you think?
What's the problem that we're trying to solve here? If we're talking about fragment identifiers for , I don't see why we need to consider other specs at all. If we're talking about fragment identifiers for , we currently have this: URL Hence I think the proposal to limit fragment identifiers to makes sense, as that'll allow targeting nearly all real-world YAML anchors while keeping future YAML-spec compatibility good. Which may later bring in "native" support for something like JSON Pointers, and which this mediatype spec should not try to pre-empt. For cases, many formats need to be embeddable in JSON as well and include some form of internal anchor syntax. Those may of may not want to make the YAML anchors addressable by fragment identifiers as well, but they get to make that choice independently, much like they do already for .
Q1. What's the problem that we're trying to solve here? Identify a fragment identifier syntax that is compatible with existing formats like jsonpath and json pointers Q2. Why? Because implementers are accustomed to use json pointers and could for example just ignore our syntax Q3. Shouldn't implementers use JSON Pointers only when using openapi+yaml ? Theoretically yes. In practice, since openapi+yaml is not yet registered, implementers just use application/yaml + JSON Pointers. Using will at the same time: enable support for alias nodes (provided that a suitable encoding is defined in future YAML version) enable implementation to distinguish between json pointers and alias nodes just using the first character. Q4. What happens if we don't find a workaround for JSON Pointers? There's the possibility that implementers will anyway continue to use JSON Pointers for processing fragment identifiers. Q4. Is there some interest in using JSON Pointers in conjunction with ? While I thought there wasn't, iiuc NAME wrote that there could be some interest for that (but please correct me if I'm wrong).
We could ask NAME if there is some space to tweak the usage of plain names as fragment identifiers. There's no reason we couldn't constrain how plain name fragments work in future dialects of JSON Schema, but we still wouldn't be able to change the media type definition because then it wouldn't support the existing dialects that don't have those constraints.
Since with plain names do not overlap with application/yaml fragment syntax, implementers could decide to process fragments where URL(0, "") =~ /^[a-zA-Z]/ as plain names and still be interoperable with YAML. This behavior won't be interoperable with other +yaml media types that redefine fragment syntax though. Question: should we specify that supporting further syntaxes in conjunction with application/yaml could create interoperability issues with future implementations? cc: NAME
Closed in
For context, I'm one of the members of the YAML core team and the author of the . We were approached by NAME primarily to ensure that the parent specification includes a proper discussion of the security considerations inherent in workign with YAML. While I strongly support defining the media type, I do not think that the should be defined at this time. The rationale given for this appears to be based on a current difference in browser behaviour, and a nominal need to communicate consumer intent from the source. Defining more than one media type is superfluous, and creates unnecessary uncertainty. The bare-text presentation of YAML content to a human is already now achievable by presenting YAML as , exactly as is the case with JSON, which canonically uses the media type. If a different medium than GitHub issues is the best way to discuss this, I would be happy to make myself available to any such endeavour.
NAME thanks for your feedback! I think this is the right place to discuss that. Happy to confirm that the yaml community is ok with . Please, integrate the other "deprecated" media types (eg. application/x-yaml, URL, ...) Agree on presenting yaml as : maybe google-chrom just uses for that and does not have a specific behavior wrt and URL I see that has been deprecated. Can you PR that change?
LGTM

Discussion:
Abstract This document registers the following media types used in APIs on the <del> IANA Media Types registry: text/yaml, application/yaml, application/ </del> <ins> IANA Media Types registry: application/yaml, application/ </ins> openapi+json, and application/openapi+yaml. Note to Readers

To increase interoperability when processing API specifications and leverage content negotiation mechanisms when exchanging OpenAPI Specification resources this specification register the following <del> media-types: "text/yaml", "application/yaml", "application/ openapi+json" and "application/openapi+yaml". </del> <ins> media-types: "application/yaml", "application/openapi+json" and "application/openapi+yaml". </ins> 1.1.

Additional information: <del> Deprecated alias names for this type: application/x-yaml </del> <ins> Deprecated alias names for this type: application/x-yaml, text/yaml, text/x-yaml </ins> Magic number(s): n/a

3.2. <del> Type name: text Subtype name: yaml Required parameters: None Optional parameters: None; unrecognized parameters should be ignored Encoding considerations: Same as Security considerations: see security-considerations of this document Interoperability considerations: None Published specification: (this document) Applications that use this media type: HTTP Fragment identifier considerations: Same as for application/json Additional information: Deprecated alias names for this type: text/x-yaml Magic number(s): n/a File extension(s): yaml, yml Macintosh file type code(s): n/a Person and email address to contact for further information: See Authors' Addresses section. Intended usage: COMMON Restrictions on usage: None. Author: See Authors' Addresses section. Change controller: n/a 3.3. </del> Type name: application Subtype name: openapi+json

Change controller: n/a <del> 3.4. </del> <ins> 3.3. </ins> Type name: application