id and $schema for meta-schemas still says "draft-04"

[handrews]

Should this be changed to "draft-05", "draft-wright-00", "v5", or something else?

[awwright]

The latest draft doesn't change the meta-schema being used.

[handrews]

It should have.

Regular meta-schema:

• Added format (bug fix)
• Should have changed several formats from "uri" to the newly added "uriref"

meta-hyper-schema:

• removed fragmentResolution
• added base
• changed method such that its description is no longer valid and needs updating

[awwright]

The explicit purpose of the latest I-D, before anything else, was to keep the existing meta-schema.

Perhaps there's some changes that could have been avoided, or withheld for a new meta-schema, but I'm not really sure how. All the changes made were in an effort to update references, clarify behavior when there was a contradiction (i.e. declare existing standards as being the "correct" one over a mere I-D), or otherwise settle fundamental problems that prevented development from moving forward; for the most part none of this impacts how an implementation is coded (except for a small handful of new features, and the "rel" magic values that to the best of my knowledge literally nobody implemented).

In any event, an I-D can't be changed, instead it'll be replaced in its entirety when a new publication is released, just like how the latest release replaced the previous I-Ds.

If we really want a new schema to describe the one new "base" property (plus "format" bugfix), I suppose we can do that. But I don't really see any need for it.

[handrews]

I'm sorry, @awwright , but none of that makes any sense to me. We're going for rough consensus and working code, and working code should include meta-schemas that correspond to the actual specification.

No matter how many times you claim that it was just a correction, you removed two keywords, added a keyword, and made an incompatible change to yet another keyword (I know you consider your change to method to be compatible, but as far as I can tell no one else agrees with you on that and the description in the meta-schema is absolutely not compatible with your new definition).

Your tolerance for confusingly contradictory publications is much higher than many of the rest of us. To me, the meta-schemas and published drafts must be kept in sync for potential implementors to easily be able to follow along with what we are doing.

While I can easily ignore meta-schemas or hack up my own, why should we make everyone do that? It costs us practically nothing to keep the meta-schemas in sync with the drafts, and that's what most people expects to find.

[awwright]

The only changes we have to include for the meta-schema are the addition of "format" (that was missed in the draft-04 meta-schema) and "base" (which might change again, I recall there was some reason that's a bad name; it may also need to be turned into an object to support customizing variables and similar features).

As far as compatibility, any schema valid against the latest draft will also be valid against the draft-04 meta-schema. "method" is still just a string. "rel" is still just a string. And the vast majority of uses will exhibit the exact same behavior.

That is, as it stands right now, the new meta-schema will describe a subset of draft-04 (by describing new keywords).

As best as I understood from your description, your use of "method" was outright incompatible with the definition of a Web link - and unfortunately there's no easy solution for that. The change I published is the best fix I'm capable of coming up with. And it's mostly intended as a stop-gap measure until we learn more about how user agents will use JSON Hyper-schema to interact with servers; despite its age and name, only fairly recently has there been research into links in APIs over Hypertext Transfer Protocol.

I think JSON Schema is one of the technologies on the forefront of hypermedia APIs, and I think so because it gets a lot of the fundamentals right. Whatever problems there are we can keep working on, I'm confident it can be ironed out in due time.

[handrews]

use of "method" was outright incompatible with the definition of a Web link

There is no "my use of 'method'". I referenced a previous project that was very loosely inspired by hyper-schema, which over-specified the HTTP operations. As I've said before, even at the time I felt like we were over-specifying it, and as soon as I understood what you were saying about links I switched to that view.

I have no need for a "solution" because I have no need to repeat that. I've tried to propose a couple of things to solve my actual problems, which you keep misinterpreting as an effort to be "incompatible with the definition of a Web link." Which is not my goal and is why I get so frustrated when you just respond to everything, including this thread with a lecture on web links.

I am not trying to circumvent web links.
I am not trying to circumvent web links.
I am not trying to circumvent web links.

Is that clear now? Please stop treating me as if I am trying to shove HTTP methods everywhere or otherwise tear up RFC 5988. While several of my proposals have been clumsy and poorly-thought out (and closed in acknowledgement of that), even those were not trying to shove HTTP methods back in. I am trying to catch up to where you are and I have not been perfect in the process.

I deeply, deeply regret ever showing that past work because you do not seem willing to let it go. It is not relevant. I am not trying to replicate it. With "method" or with anything else. No issue that I currently have open is trying to do that. At all. In any way.

[handrews]

"method" is still just a string.

That is not the point. Have you read the meta-schema? This is the problem:

"method": {
    "description": "method for requesting the target of the link (e.g. for HTTP this might be \"GET\" or \"DELETE\")",
    "type": "string"
}      

Do you see the explicit reference to HTTP methods there? Specifically DELETE, which is excluded by your current wording? That is not compatible with your revised definition of "method."

[handrews]

To acknowledge what is probably confusing you, I do have other concerns around method, but they are not relevant to the meta-schemas and have nothing to do with making HTTP verbs explicit.

[awwright]

I understand it's a bit of a stretch, but the draft-04 meta-schema is still technically correct, and shouldn't be breaking anything.

I'm merely trying to describe my impression, however limited. Any changes were motivated by not only by fixing inconsistencies, but avoiding breaking implementations that I reviewed. You still have an outstanding invitation to join us on IRC to discuss your hyper-schema usage and interest, I'm very interested in making sure that everyone is able to have their needs met.

[handrews]

You still have an outstanding invitation to join us on IRC to discuss your hyper-schema usage and interest

In #48 you specifically told me to keep the conversation in issues, so that's what I've been doing. I will try irc as soon as I get a chance.

You continue to miss the point about the meta-schemas. Even if all draft 05 schemas will validate against draft 04, the meta-schemas do not make sense when read next to the current draft. That is confusing to people. It is also completely unnecessary. Your refusal to address it is baffling. There is no downside to updating the meta-schema. No one is forced to use the updated one.

[handrews]

Meh. My last reply (or perhaps several) are just me repeating the same things more loudly, which is an abysmal tactic and not particularly nice. I apologize.

There's clearly no point in further debating the current state of things as you've made clear they can't be changed. I accept your intentions with keeping the meta-schema for draft 04, although I still do not believe the current state of things achieves them. But that's fine, my opinion doesn't change anything about the current state either way.

I will drop all of this stuff, but make the necessary changes to bring the meta-schema in line with the spec as part of the draft 06 work.