W3C Recommendations are well-suited for traditional specifications whose implementation is largely independent of platform-specific, non-web-related technologies. W3C Notes are well-suited for best-practices documents related to Recommendations. But I believe neither are fully compatible with specifications with normative requirements that depend upon technologies which are platform-specific and/or non-web related.

My particular use case is accessibility "mapping" specifications, such as:

• HTML Accessibility API Mappings 1.0
• Core Accessibility API Mappings 1.1
• Digital Publishing Accessibility API Mappings
• SVG Accessibility API Mappings
• Graphics Accessibility API Mappings

Each of the above W3C specifications "maps" W3C-specified elements and attributes to platform accessibility APIs such as NSAccessibility (macOS and iOS); ATK (GNU/Linux); IAccessible2 and UIAutomation (Windows). These "AAM" specifications are not best practice: There is a "right way" for user agents to expose the aforementioned elements and attributes to assistive technologies as part of their implementations. The failure of a user agent implementation to do what is specified in an AAM negatively impacts the accessibility of the associated content.

Unfortunately (for W3C Process), what is specified in AAMs is outside of W3C governance. Accessibility APIs are tied to the needs (and release cycles) of the platforms on which they are used. If a given platform adds or removes accessibility API, it can render the AAM technically incorrect even though nothing has changed in the W3C-governed technologies. When this occurs, W3C Process doesn't seem to give us many options:

• Adding errata: Not a great fit IMHO because it requires implementors to look in multiple places in order to know the correct implementation. Besides, the AAM was presumably correct at the time it went to Rec.
• Following the Rec-track process, starting at CR: Potentially a non-trivial amount of work. And it is work which must be repeated every time one of the four mapped platforms makes a change which user agent implementations must support.
• Making the change in the user agents without updating the AAM: Can lead to the view that the AAM is not a reliable specification, and also to user agents getting out of sync with one another which impacts the web as a consistent platform.

Furthermore, it is worth noting that the above issue and available courses of action provided by Process are not limited to a single AAM: If a platform changes its accessibility API, odds are that at least the HTML AAM and the Core AAM will each have at least one mapping which has been rendered outdated/inaccurate.

Having said all that, I do believe that all stakeholders benefit from there being normative specifications which clearly state the accessibility mappings for W3C specifications. Thus I don't think we should abandon the AAM approach. Instead, I think we need some new middle ground between Recommendations and Notes which allows for the AAMs to remain up-to-date, reliable, normative specifications that live under the same umbrella (W3C) as the specifications whose features they "map" -- and to do so without the need for frequent repeated trips through the Rec-track.

Following the Rec-track process, starting at CR: Potentially a non-trivial amount of work. And it is work which must be repeated every time one of the four mapped platforms makes a change which user agent implementations must support.

What makes the Rec track so burdensome for this use case? Some WGs (e.g. Web Platform) have established 12-month rhythm for updating key Recommendations to adapt to changing external reality. The new Web Assembly WG aspires to ship updates on a 6-month rhythm.

I agree that the Rec-track process is potentially a lot of work, and certainly is if there are patent disclosures to work around, political controversies to try to resolve, or major changes that have to be implemented and tested. But those don't seem likely to apply to AAM -- it's authoritative guidance for how to map the standard APIs to real-world ones, so patent concerns are unlikely, it seems politically uncontroversial, and the changes are driven by already-implemented reality.

I'm not opposed to a middle-track that is faster and easier than the Rec Track but more authoritative than CG Reports or WG Notes, but I'd like to see the Rec Track continue to evolve to be more lightweight and agile. We've already combined Last Call and Candidate Recommendation. I could imagine allowing specs that are expected to change regularly to go through CR and PR simultaneously with the understanding that review feedback will be applied to the next iteration. (I'm not sure that's forbidden in the current process, but it's not explicitly allowed).

Anyway, thanks for bringing this use case to our attention, we need to make sure some track of the W3C Process works for it!

@dwsinger wrote

For some kinds of things, they’d be busy work to get the IPR commitments, and yet we’d want the outside world to treat them as having less status in every other respect. Want the latest database? Use the latest WG-approved document, not the older snapshot, and so on.

I see, maybe the AAM use case is for something more like a registry than a standard. It would be the product of a group of experts and a community that generally treats the document as authoritative, but it would not need / be burdened by patent commitments, review by the entire W3C, proof of implementability, etc.

I can envision adding to the process something like a "W3C Database" (for lack of a better term off the top of my head) that has just enough process to ensure that a WG has reviewed and put its credibility behind updates, but doesn't require all the busy work to get wide review, patent exclusion opportunities, etc.

What makes the Rec track so burdensome for this use case?

TL;DR: What you've subsequently stated, namely: "patent commitments, review by the entire W3C, proof of implementability, etc."

DETAILED EXAMPLE:
To add some context about the sorts of changes we're talking about, on my platform (GNU/Linux, ATK), the following mappings are about to become obsolete/incorrect:

• aria-valuemax
• aria-valuemin
• aria-valuenow
• aria-valuetext

The reason why is the deprecation of the specified AtkValue methods. While we know the new API, user agents MUST NOT implement that new API yet because if they do, it will break accessibility of the aforementioned ARIA features. The reason why things will break is because we also need to make some changes in the client-side AT-SPI2, changes which we cannot currently make due to code and API freezes in GNOME. But once user agents are able to implement it without breaking accessibility, user agents really, really SHOULD (and I would say MUST) do that implementation because the new API offers platform assistive technologies a more efficient way to accomplish presentation of these ARIA features.

The changes will be:

• atk_value_get_maximum_value() -> atk_value_get_range()
• atk_value_get_minimum_value() -> atk_value_get_range()
• atk_value_get_current_value() -> atk_value_get_value_and_text()
• object-attribute: valuetext:<value> -> atk_value_get_value_and_text()

Why does the above need a 60-days exclusion opportunity, or Advisory Committee Review? One month for comments even seems unnecessary: Authors have nothing to do differently, and only one platform (GNU/Linux) is impacted. Getting the implementations done will be quick and easy and simple to prove. In fact I can have the implementations for all (currently two) accessible user agents on my platform in place prior to asking for the transition to CR, in which case what exactly is the benefit of getting Working Group consensus to transition to CR (it would almost certainly be a rubber stamp), having the Team Contact do multiple transition requests, getting the Director to approve each transition, etc., etc.?

As a related aside, there is also some AtkValue API which will improve the accessibility of the HTML meter element. So HTML-AAM will need to be changed. Just not quite yet.

Getting back to the original question, it's not so much that the Process is burdensome for the average spec, or even for going from something like Core AAM 1.0 to Core AAM 1.1. But the amount of people and steps involved, along with the ~2 months needed to go from CR to TR, strike me as an unnecessary price to pay for maintaining the technical accuracy of these specifications.

To be clear, I do not believe anyone is suggesting ARIA should move to a living standard. The general ARIA spec is a good candidate for remaining on Rec Track b/c it's a cross-platform Web API with requirements for two implementations per feature. However the ARIA-related Accessibility API Mapping documents (AAMs) are effectively platform glue: how does feature X of ARIA map to each non-Web platform API.

I support (and have previously suggested) that all the AAMs be moved to a "living" process. If our options remain limited to Note or Rec, I'd vote for Note, but as Joanie eloquently pointed out, these are normative documents, albeit ones that need more frequent updates than the standard W3C specification.

Because the AAMs simultaneously reconcile a single Web API with four or more platform APIs, there will always be something out-of-date, no matter how often the group publishes. By design, the AAMs document implementation details of each platform, which makes them unlike any any other W3C Rec, and worthy of a process reconsideration. Furthermore, each edit usually only affects a single platform, and the source of the edits is usually the API owner, so these changes have almost no risk of "breaking" another implementation. A "living" document process would allow the editors to make necessary changes without unnecessary bureaucratic overhead.

I believe that there are a collection of items that do require standardization, need a consensus process, but also need to evolve in a very flexible and lightweight fashion (aka Living Standard).

I think that W3C would benefit if we had a formal lightweight process that had several pieces to it:

The nth version of the standard is stable.
It is easy to add a few branches to this version and call it the n+1st version.
Initially there are no patent commitments to the deltas in version n+1.
At some point in time (maybe after n+2, or n+3, etc.) there is enough change that we formally take it through a REC process to finalize patent commitments.
Even while doing (4) we are already branching out to the next version.

My favorite application for such a living standards process has been to standardize Vocabularies. It would fit this model very nicely. Another application would be for Maintenance. My guess is that it would fit AAM as well.

I have not formally proposed such a process because I think creating a new process path within W3C is expensive and potentially confusing. I'm not sure if it would pay to introduce it just for AAM. So as Mike said, we kinda can get it done already.

My favorite application was going to be schema.org. Schema.org (imho) deserves more attention than just a mere CG. It is important enough to have greater status as a standard, but it is a poor fit for the REC process. Unfortunately, I was never able to convince the schema.org organizers of this plan. So I never proposed this mechanism.

In line with the above, I had put thought into characteristics of content that seem to have more pains than benefits from the Rec track process, yet is not necessarily something we want to demote to the Note track:

• So simple that it's not likely to have valid copyright or patent claims;
• Not of great interest to the majority of the AC, even while it's at least supported in principle;
• Requires strong technical knowledge of a very particular area in order to have an opinion about the technical decisions made;
• Should have more consensus behind features than just that of an editor or two;
• Needs to be documented and used but perhaps not having a major implementation base compared to other W3C implementation targets.

We've seen accessibility API mappings and schema vocabularies as examples of content potentially with these characteristics; there are probably other examples we could find.

The goal of describing these characteristics is to help focus on what problem we seek to solve, and identify a solution that actually addresses that problem. I don't think "living standards" as I understand the concept is the right solution but recognize there is a problem and intend to continue working on it with my WGs and the Process. I hope to be able to put more thoughts on the subject here soon.

There are different definitions about what a Living Standard is, and different use cases. For Process 2019, we might take a broad look at these: API mapping, schema vocabularies, regular specifications, maintenance all present different use cases.