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.

Strawman proposal (more a thought experiment than a serious proposal at this stage): Create a Living Standards Track in the W3C process similar to the new WHATWG IPR process, but retaining the traditional W3C concern for broad, formal consensus with the Director as the ultimate arbiter. See https://whatwg.org/ipr-policy and https://blog.whatwg.org/working-mode-changes for a summary of the new WHATWG process, which is itself a mashup of the W3C Community Group and Standards Track processes.

Briefly:

• Those joining a Living Standards Track Working Group (LSTWG) would have to agree to a CLA similar to that for Community Groups offering royalty-free patent commitments on their own contributions to specs.
• The group would operate day to day like any WG, with a charter, chairs, editors, making decisions by consensus, to draft and update specs.
• The LSTWG would publish Living Standards, roughly equivalent to regular Working Drafts, when there is consensus to do so. The LSTWG would continue to update the Living Standard as long as its charter lasts and there is energy to keep working on the spec, on whatever rhythm it chooses.
• Periodically (yearly?) the LSTWG would prepare a Proposed Snapshot Recommendation. This would trigger a patent exclusion period; LSTWG members who do not exclude a specific patent during that period incur a binding patent commitment just like when a regular WG publishes a Recommendation.
• The Advisory Committee is informed of the Proposed Snapshot Recommendation and members have an opportunity to formally object to it being published as Snapshot Recommendation. I envision this as a "silence means assent" ballot rather than a regular AC ballot, but it could be run just like a PR ballot if others prefer.
• If there are no objections, or the Director over-rides objections, the Proposed Snapshot Recommendation becomes a Snapshot Recommendation. This term would clarify that the WG does not consider it a completed product, but just a snapshot to describe those features at a particular point in time that have broad, binding patent commitments.
• Other specs would be strongly encouraged to normatively reference the Living Standard, not the Snapshot Recommendation since that is where the most recent updates and bug fixes would reside.

This addresses a few challenges with regular WGs and Recommendations:

• Patent commitments from contributors are triggered as soon as the contribution is made, not years later when the spec gets to Recommendation. This is a feature of the Community Group IPR policy that is lacking in the Rec Track IPR policy.
• Broad patent commitments are locked in on a regular schedule, they aren't delayed until a WG thinks a spec is "done" and all the comments and objections are resolved.
• It appears to address the use cases / problems with the rec track process noted in this issue -- it can create authoritative specs for things like mappings to system APIs that change on an unpredictable schedule.
• It should encourage specs to be maintained by making continual updating the normal activity of a LSTWG. SInce a spec is never "done", all involved should expect it to need ongoing attention.

It does create new challenges:

• The LSTWG would have to impose a discipline on itself to minimize "breaking changes" during the ongoing development/maintenance process.
• Those making normative references to the spec would need to do extra diligence to reference those features in a spec that are least likely to change in ways that would break the referring spec.
• Determining the right rhythm for snapshots/patent exclusion periods could be tricky, and likely to generate concerns from overworked lawyers. The LSTWG would probably need to take extra care to create accurate but usable-by-lawyers change logs describing the delta between one snapshot and another.
• Probably more challenges I haven't thought of....but I envision this as an experimental supplement to the existing Rec Track process, much like CGs were an experiment when launched in 2010 or so. If LSTWG's turn out to be successful, perhaps that would inspire changes to the Patent Policy in the future.

I wonder whether we need two different issues here.

Joanmarie's original post looked for a LS model for AAM's; and I posted that having such a model would help not only AAM's; but also vocabularies.

Mike's proposal would apply to a much broader set of specs.

It is probably the case that both use cases are worth addressing, but we might address them on different time scales.

@michaelchampion wrote:

Strawman proposal (more a thought experiment than a serious proposal at this stage)

This seems a lot like the approach used by the Web Platform Grop for HTML. The biggest difference I can see is no requirement for FPWD for specs that are being revised, and the addition of a contributor license.

Not requiring a FPWD to revise a Recommendation seems in principle useful. One impact would be that there is no exclusion period, and therefore no commitment, to anything until the CR (or Mike's equivalent). For a spec that is going to Rec/snapshot stage more than every three months, this makes no difference, for every six months it is probably not that significant, but for a spec stabilised once per year that seems easier on the lawyers but more likely to induce frustration if someone does want to exclude something.

Having a CLA seems useful. In practice I think it is less valuable than it seems, since a significant proportion of features are not contributed to the specification by the people or even company that developed them but instead by someone else who figured out how it worked - but who almost certainly doesn't hold the relevant IPR in the first place.

It doesn't seem to address the use case raised at the beginning of this, which is IMHO for a registry that is relatively straightforward to update but has a formal status like a Recommendation - and for which there is a need in various groups (I know of at least HTML and WCAG as likely users, before I try to think).

@jeffjaffe wrote:

I wonder whether we need two different issues here.

Yes, I think "streamline the Rec track process", and "allow registries to be created that support Recs" are pretty different issues.

@joanmarie could you look at #168 and see whether the linked Wiki and this issue are heading towards addressing your original request?

see https://www.w3.org/wiki/Living_Standards

AB input and any more team input by Apr 19th

@dwsinger: Sorry for the delay. Been traveling. I'll take a look today or tomorrow.

@cookiecrook: Your input would also be helpful as you also had voiced this need.

Jeff wrote:

I posted that having such a model would help not only AAM's; but also vocabularies.

FWIW, we have an emergent situation with WCAG and a newly proposed SC that lists a fixed list of form inputs that will require attaching metadata to them (for personalization). Currently the CR Spec points to the token value list associated to @ autocomplete in HTML5, but there is a concern about ensuring the list remains fixed (and self-contained with the spec. See: w3c/wcag21#803).

While the autocomplete values have a specific browser function, AG WG sees this list as a rudimentary taxonomy (terms and definitions), which also meets some basic needs for personalization. The AG WG had debated including these values as an Appendix to WCAG 2.1, but because it needs to be a machine-referenceable taxonomy there were some concerns going forward that way, and the current 'solution' still introduces some brittleness into the situation.

Having a repository as Jeff suggests would be a great solution to this issue, and so a vote of support for further exploration in that direction.

(See also: https://w3c.github.io/personalization-semantics/#vocabulary-implementations for a related and similar use-case. I believe an official "W3C Repository" would be extremely useful there as well.)

please see https://www.w3.org/wiki/Living_Standards for comments

from the draft in the wiki:

Your licensing commitment is to any essential IPR in an agreed draft when there is a period of continuous essentiality that includes that agreed draft and lasts for 225 days or more, with no agreed drafts in that 225-day interval in which the IPR was not essential. (“could have excluded and did not”).

Does this introduce a motive for periodically removing a feature from a draft so it does not become essential? Using e.g. Echidna this is pretty easy to do, and tempting for lawyers to request, but the consequences seem unclear.

It clearly runs counter to the motivating idea that engineers don't worry (much) about IPR issues - but being easy to implement there may be a temptation to do it as a way to avoid issues.

Or it may be a theroetical possibility that isn't worth much real time because it won't really happen.

Yes, both a snapshot and this continuous model have this. I have to assume that getting the consensus of the WG to remove a feature periodically "in order to avoid licensing commitments" ought to be hard.

I propose putting the Evergreen standards into a 'sandbox' with their own experimental process and IPR policy. These would be developed and approved in the usual way for these documents, viz; (a) the process CG, AB, and team and AC approval for the process and (b) PSIG, team and AC approval for the patent policy.

To enable this, I think we should insert one line into the current process, in 6.0. "Recommendations and Registries may also be developed or maintained using a formally approved experimental Evergreen Standards process."

Seems like a slightly scary door to open, but if we're going to, then we need to require that whatever process is being followed is documented on a permanent space (e.g. the process itself can't be on a wiki page) and linked to from the document being developed or maintained.

I don't think this opens a door; I agree, the documents should be as stable as the process and patent policy. I'm trying to confine such experimental documents to a small sandbox, so that if we fiddle mid-year, such fiddling can't affect the general process or the stable patent policy.

I'd like to pipe in with support for this as a feature. Especially for newer standards, implementation experience is going to grow significantly after the first recommendation. An evergreen recommendation can effectively capture that learning.

For registries, this seems like the only way the process can work well.

I also agree that as we explore the process, an experimental attitude towards evergreen recs is a good idea. I'd expect as we get a few years into the process, that "experimental" aspect will mature into standard procedure.

Some comments from discussion in the Patents and Standards Interest Group (PSIG). minutes member-only

• Will there be a regular cadence for publication of snapshot review drafts? Given the potential number of W3C specs that could be using this process, lawyers might like to have a schedule to anticipate reviews.

• Is there any exclusion period for a contribution commitment?

• When a participant leaves a group, what happens? (Do they get an exclusion opportunity on the things added since the last RD?)

• Notifications. It's important to ensure good notice (email) of exclusion opportunities and commitments.

• How would the experimental Process be rolled out?

Some of these are questions for the associated Patent Policy I'm drafting, but the cadence and roll-out are probably good questions for this group.

this may be just a part of what this issue discusses (which is related to #168, i guess?), but in case anybody is interested: i just posted an updated draft of my "the use of registries" document, and i have added a list of w3c specifications that currently are using some shape or form of a "registry", but are doing so in a rather ad-hoc session because there is no process or even guidance (afaict). here is a direct link to the section listing W3C specifications: https://tools.ietf.org/html/draft-wilde-registries-02#appendix-A

@dret Thanks, Erik, this is really helpful.

The Revising W3C Process CG just discussed github: https://github.com/w3c/w3process/issues/79.

The Revising W3C Process CG just discussed IPR of Evergreen.

Here is the list of candidates mentioned at the AC meeting:
[[
ARIA: ARIA Mappings
SVG: Beyond SVG 2
WebAppSec: CSP
Web Performance: performance timeline, …
Web Platform: WebIDL
Dataset Exchange: Beyond DCat 1.1
Timed Text: TTML Profile registry
Distributed Tracing: Trace Contact Protocol Registry
WebRTC: registries
WebApps: Manifest, etc.
]]

To this list, we can also add Web Assembly and Service Workers. Imho, it would be best to limit the experiment to registries and specifications that were published as W3C Recommendations in the past.

The TTML Profile registry might be suitable but this has not been discussed in the TTWG. I think the reason it ended up on this list was from a query about existing registries; that's not an indication by itself that the TTWG would choose the LS approach. It may or may not, we don't know yet.

with apologies to Mike for being slow.

Thanks for putting this into Process-speak, it makes it easier to grok what's being proposed! My first impression is that there's more new terminology than needed. For example, what's the distinction between a Working Draft and a Preliminary Draft other than one is a step toward Recommendation and one is a step toward Evergreen Recommendation?

I think we should have a uniform name across the tracks for darfts that precede formal status (before FPWD for Rec track, before Evergreen for that track).

More generally, seeing this all in the Process Document context leads me to think that Evergreen should not be a separate track so much as a possibly permanent CR-like phase. Could all the 6.11 text be made into CR requirements, e.g. the feature level tagging and the requirement to renew snapshots and re-open exclusion opportunities on some rhythm? This would address a bug in the traditional process, that patent commitments only lock in once a spec gets to Recommendation, and things can get stuck in CR for years for various reasons. That would compose better with the WHATWG process -- Living Standards are roughly equivalent to Evergreen Standards, but a snapshot of either can move through the PR-> Rec process if there is broad enough review, consensus, and "Director" signoff. I also think it could address the maintenance problem: the norm is that ALL W3C specs are actively maintained because the implemented web is evergreen; declaring "we're done" and walking away is a sign that the spec is no longer really a viable part of the web.

I agree that
a) in time we may well want to do all maintenance evergreen-style. I am hesitant to disrupt the Rec track with an experiment, though, and feel safer merging later
b) many of the tricks and tools and techniques here are broadly applicable across both tracks (notably, improved tooling so that review groups can and should comment on issues, and on PRs before they are taken, and more rarely on stuff that's happened).

@dret re #79 (comment) I don't think that is an extreme position at all. From what I've seen that is the usual position.

I support @frivoal and @michaelchampion's position that we should merge the proposed Evergreen Recommendation track and the current Recommendation Track as much as possible--even if there remains some divergence, it should be absolutely minimized. This will reduce confusion, ensure that improvements required by ER are incorporated into the REC track, and ensure that the ER track does not regress from the REC track or diverge from it unnecessarily. If tackling this properly requires more time, I would rather delay the implementation of Process 2020 to get it right than deploy an entire new standards track prematurely and have to deal with untangling the resulting snarl of processes in 2021+.

a) in time we may well want to do all maintenance evergreen-style. I am hesitant to disrupt the Rec track with an experiment, though, and feel safer merging later

The REC track is currently seriously problematic wrt REC maintenance, and it needs to be fixed. I consider its current state to be a disruption. https://lists.w3.org/Archives/Public/public-w3process/2019Mar/0076.html

@fantasai I also agree that we should merge the proposed Evergreen Recommendation track and the current Recommendation track as much as possible.

However, I don't support delaying the ER track until we accomplish the merge. At the moment the ER proposal has been in the Process CG for several months with not a large number of issues against it. There is also progress in PSIG to define an Evergreen PP.

For the REC track, on the other hand, we have barely scratched the surface of raising the issues and proposing solutions. And to my knowledge work has not even started in PSIG.

My preference would be that those that want the Evergreen Track aggressively push to get it defined. Those that want fixes to the REC track aggressively push to get it defined. Once there is more progress we see whether they are close enough to merge and do at the same time.

I propose that we focus on what is common to the "ER Track" and "and ER state in the Rec track". I believe that's roughly:

• The definition of the ER entrance criteria
• A clear understanding of how wide review of ER specs would work (as part of the ER entrance criteria and/or as changes to an ER are made)
• An agreement on how to move from the ER track/state to PR/Rec
• An IPR policy update that meets the "ER track" requirements (and IMHO could be applied to the Rec track as well, but that's another question)

On Registries,

Here are the use-cases, collated:

from @joanmarie mentions Aria API mappings. @dret mentions https://tools.ietf.org/html/draft-wilde-registries-02#appendix-A
@plehegar mentions:
Here is the list of candidates mentioned at the AC meeting:
[[
ARIA: ARIA Mappings
SVG: Beyond SVG 2
WebAppSec: CSP
Web Performance: performance timeline, …
Web Platform: WebIDL
Dataset Exchange: Beyond DCat 1.1
Timed Text: TTML Profile registry
Distributed Tracing: Trace Contact Protocol Registry
WebRTC: registries
WebApps: Manifest, etc.
]]
add Web Assembly and Service Workers.
@nigelmegitt also mentions The TTML Profile registry

In the #168 I mentioned:
https://www.w3.org/2011/07/regreq.html

TTML uses:

https://www.w3.org/wiki/TTML/RoleRegistry
https://www.w3.org/wiki/TTML/ItemNameRegistry

And perhaps more importantly the media type registry with short form
profile designators for TTML is at:

https://www.w3.org/TR/ttml-profile-registry/

there is an XPointer registry:
https://www.w3.org/2005/04/xpointer-schemes/
It has an ad-hoc script for adding entries:
https://www.w3.org/2005/04/xpointer-schemes/0register
We don't know if that is just supposed to deposit email in someone's mbox
and whether that person knows of their mandate.

vdbrink mentions the EPSG registry, but neither link supplied now works
kcoyle mentions the Open Metadata Registry,

The document https://www.w3.org/2011/07/regreq.html mentions

• xpointer registry http://www.w3.org/2005/04/xpointer-schemes/
• RDFa URL prefix / not really a registration, a shared space/community
• SSML pronunciation alphabet http://www.w3.org/2001/10/synthesis
• old micropayment names http://www.w3.org/TR/1999/WD-Micropayment-Markup-19990825/#Appendix%206
• webapp clipboard data type (sub mime?)

alvestrand mentions stats registry in https://w3.github.io/webrtc-stats/

webauth may have need, see w3c/webauthn#1177

It would be helpful if people involved with W3C 'proto registries' could comment on https://www.w3.org/wiki/Registries#Proposed_Process_Text_.E2.80.93_Registries

(This message duplicated from #168 in order to catch all authors)

This issue was forked into Ever* and Registries. Registries have other issues such as #168 , and Ever* is handled in P2020. Closing.