New self-identification proposal

[handrews]

Without the bundling this time.
For OAS 3.2 and Arazzo 1.1.

[jeremyfiel]

couple nits.

Looks good and the proposal is clear. Nice job!

[jeremyfiel]

Many tools effectively by allowing the retrieval...

I think you missed something here

[jeremyfiel]

Suggested change

	While including `self` in every Object would produce the same complexity as JSON Schema's nested `$id`, we could just adopt an equivalent of JSON Schema's `$anchor` keyword, which (like HTML/XML's `id` attribute) creates a plain name fragment that is not tied to the location of the Object in the JSON/YAML structure.
	Including `self` in every Object would produce the same complexity as JSON Schema's nested `$id` but, that introduces unnecessary schema bloat rather than a single identifier at the root.
	Adopting an equivalent of JSON Schema's `$anchor` keyword, which like (HTML/XML's `id` attribute), creates a plain name fragment that is not tied to the location of the Object in the JSON/YAML structure.

[jeremyfiel]

Suggested change

	Handling this would require scanning all Objects for the keyword prior to declaring that a reference target with a plain name fragment cannot be resolved. This would likely be done on document load, but could be deferred and done incrementally as-needed when unknown fragments are encountered.
	Handling `$id` or `$anchor` requires scanning all Objects for a defined keyword prior to declaring that a reference target with a plain name fragment cannot be resolved. This would likely be done on document load, but could be deferred and done incrementally as-needed when unknown fragments are encountered.

[ralfhandl]

+1, only minor nits

[handrews]

@jeremyfiel I've updated everything that I think was needed for clarity. I am aware that you dislike my writing style, but as this is not even specification text, unless and until someone writes a style guide for proposals, I'm going to stick with writing in my own voice. In some cases I reworded thing to incorporate what I felt were the bits that needed clarifying while sticking closer to my preferred wording.

[jeremyfiel]

I am aware that you dislike my writing style

That's definitely not my intention and I understand this is not specification text. I only provided nits on clarifications I thought would enhance the understanding. (at the very least, my own)
Forgive my impression that I dislike your writing style. I don't have any qualms against it :)

[handrews]

@jeremyfiel

Forgive my impression that I dislike your writing style. I don't have any qualms against it :)

Of course- in that case please forgive my over-reading of whatever past comment made me think such a thing :)

I only provided nits on clarifications I thought would enhance the understanding. (at the very least, my own)

In some cases in this PR I couldn't really tell any difference, and it felt like you just wanted a different tone or preferred different words, which is the other reason I got the impression of just wanting a different style of writing. I didn't really want to go critique each suggestion, so I was hoping that I got enough of what really wasn't clear.

Sometimes if the suggested change is not an obvious problem (e.g. duplicated word, or a sentence that clearly makes no sense like the one you pointed out had something missing) it might be better to start a conversation about what you find confusing. Then there's a little more flexibility in how to solve it.

[mikekistler]

Looks good! 👍

[handrews]

Since @mikekistler 's approval was only cleared because @ralfhandl merged Mike's suggestion and then approved it himself, I'm considering this to have two TSC approvals. Since all other commenters have since approved, I'm going to merge this.