Show that we are an active project

[handrews]

The front page doesn't really make it clear that the project
is as active as it is. Let's put up some actual text on that,
and link to where people can see the status and timeline of
the various drafts. And a link to the current active milestone,
which will need to be kept up to date but twice a year isn't
exactly burdensome. And if it's out of date people will see
that the milestone is complete and figure it out anyway.

Unlike the other tweaks to the web site, I plan to leave this
PR open for a while as it's a significant change to the feel of things.

In addition to @adamvoss, I would appreciate if @awwright and @Relequestual could take a look.

[adamvoss]

My concern is that it does not talk about end-game at all. Is the plan to publish ever 6 months ad infinitum? From a corporate perspective, that is much more frequently than I would like for a technology that covers my data and gives no compatibility guarantees.

It would be nice to say you are working towards stability/finalization (if true).

[handrews]

@adamvoss while I have always considered that as inherently obvious to the IETF I-D process, which is intended to produce RFCs, I suppose that may not be obvious to all visitors. So that's good feedback and I will add something. The next step in the process is to get the specifications adopted by an IETF Working Group, so perhaps we can link to a description on the IETF site of what that entails.

---

You also bring up a good thing about the 6 month schedule: The idea is not to thrash the spec around every 6 months. Let me explain and perhaps you can suggest how to convey this better.

For all of the specifications, draft-06 introduced some incompatibilities, but should be a stable base moving forwards, to which we make additions and bug fixes. In Semantic Versioning terms it would be a major release, with further drafts intended to be minor or patch releases (although that is definitely not a guarantee, about which see below).

Core and Validation

Core and Validation are both quite usable and widely adopted.

• draft-05 just improved wording and fixed what was essentially a bug in the uri format value
• draft-06 made a few breaking changes to features that were very confusing (id vs $id, the exclusive* keywords) and added a few features
• draft-07 validation is entirely backwards compatible with draft-06, and adds only one new implementation requirement. With core, it may change how schemas are linked, but that's not widely implemented AFAIK and would be changed due to it having been improperly specified in the first place

I expect future drafts to mostly be like draft-07: adding things that are widely agreed to be gaps, and fixing bugs. Draft-08 may be an exception, as it is focused on the whole re-use / additionalProperties area, on which people are bitterly divided and which killed the project in the wake of draft-04. The uncertainty there is a barrier to further adoption, which is the other sort of thing I expect to see resolved in the draft series.

Maybe we should have a page that sketches out a tentative road map? @awwright I know we've avoided this in the past but I think that noting the major topics still to be addressed, and putting a very tentative order (not schedule) on them, with a note about how it is subject to change based on community feedback, might be good. We could then link that from the front page, which would just have the note about how the drafts are aiming to resolve major open issues and get us to IETF Working Group adoption. Thoughts?

Hyper-Schema

The situation with Hyper-Schema is very different. It has never been broadly adopted. Or even adopted much at all. Geraint's jsonary is the only known implementation of draft-04 for anything other than generating static docs. And generating static docs isn't really what Hyper-Schema is for (although it's useful as a partial solution for that).

• draft-04 split it out as a separate spec, but also introduced logical inconsistencies around method
• draft-05 restored philosophical coherence based on HTML analogies that had been present before draft-04, and removed unnecessary features, but also brought back the confusions that led to draft-04's problems
• draft-06 began replacing the HTML analogy with a more API-oriented philosophy, producing major breaking changes compared to all previous drafts
• draft-07 continues that direction, remaining compatible with draft-06 but filling in gaps in a way that is not compatible with draft-05 or earlier. It defines, for the first time, what an implementation must do to conform to the spec

My hope is that draft-07 is a stable base for future hyper-schema drafts. It will have a test suite, and hopefully soon a reference implementation (that I am writing).

It's road map is a little less clear- the vast majority of open hyper-schema issues have a resolution in draft-07, so where we go from here will be based on feedback more than anything else.

I would not be surprised if core and validation reach Working Group adoption before Hyper-Schema does.

[handrews]

@adamvoss given the other approvals I'm going to push this and do a follow-up PR addressing your concerns.