Henry Andrews

@ralfhandl we have not resolved #4865 regarding a 3.0.5 or errata, and I am still concerned about 3.0.4 misleading tooling developers and complicating the upgrade path. We should not do...

I'm still not giving up on fixing the accidental but egregious errors (giving the completely wrong instructions on handling URI percent-encoding in header parameters, for example, in ways that will...

@lornajane @ralfhandl of course if we solve the 3.0.4 issues with errata instead of a 3.0.5, we could hot-patch the errata links on `main` rather than having a `v3.0-dev` (as...

@lornajane @ralfhandl let's take this broader discussion to #4865. I will write an updated summary of my position there.

I'm not taking a position on this, but I want to point out that making the schemas normative means that if they say something that disagrees with the specification, then...

@ralfhandl > Fully agree with your points on "non-normative" and "non-authoritative": the schemas are normative and supplement the spec, validating against the schemas is necessary for correct OADs, even if...

@ralfhandl I'm philosophizing at this point, so take it with a grain of salt, but... I think the main issue is the potential for conflicts. But perhaps we can call...

The language in the spec is intended to say that tools are, in fact, _not_ required to use the schemas. Up through and including 3.1.0, there weren't any schemas at...

@ralfhandl yeah this is a perfect example of why the schemas are informative. And also shows some challenges here- this is a field that very few people use, so the...

> but we can still assert that the schemas are believed to be correct Publishing them means we believe they are correct. We just say that _if_ there is an...