Living Standard?

[svgeesus]

Describe the Issue

We have two options for Web Audio post-1.0. Which we pick affects the Proposed Recommendation for Web Audio 1.0 which is why I am raising the issue here.

Firstly, the traditional route where Web Audio 1.0 Recommendation is essentially frozen, it can list errata in a separate document and can be updated every few years to roll in the errata but can't have substantive changes or new features. All new work goes into a separate specification, like Web Audio 2.0

Secondly, and this is new, the Proposed Rec and the Rec can allow new features. (Even if we do this, we don't have to use this capability. But if we don't allow this, we cannot ever add substantive changes or new features. So we need to decide now).

The second option means that Web Audio becomes a living standard. It is always at Recommendation, but it can be revised to add candidate corrections and candidate additions - changes to existing features, and brand new features.

I recommend this second, new option because there is then only one Web Audio API specification and it keeps moving forward, always reflecting the current state of the work.

[hoch]

+1 on "the Proposed Recommendation".

It sounds great for everyone, but then why does "Recommendation" exists? What's the downside of the proposed rec?

[mdjp]

+1 for the new approach from me also. It sounds very positive. Is there a downside to going down this route, will it delay the process for v1 at all?

[rtoy]

Teleconf: People were generally supportive of a living standard, especially since there we don't have to use this ability if we don't want to. But we had questions on exactly how this would work and how we manage getting appropriate review for new additions.

[svgeesus]

The magic words to add to the Proposed Rec and Rec are:

Future updates to this Recommendation may incorporate
 <a href="https://www.w3.org/2020/Process-20200915/#allow-new-features">new 
features</a>.

which includes a link to the process document to describe how this works.

The new features get added to the spec as candidate additions and review happens by Last Call for Review of Proposed Changes which combines an AC review and an exclusion opportunity. This happens after the given change has met the usual CR implementation criteria.

So in practice, after publishing the initial Recommendation, it just keeps getting republished. It is always a Recommendation; but (for each addition) parts of it are candidate additions and parts of it are more mature and under last call review, and then those parts become a regular part of the Recommendation.

[svgeesus]

It sounds great for everyone, but then why does "Recommendation" exists? What's the downside of the proposed rec?

Proposed Recommendation is a temporary state that only exists for 4 weeks while the W3C Advisory Committee does a review (not a technical review, at this stage). It then becomes a W3C Recommendation.

Is there a downside to going down this route, will it delay the process for v1 at all?

No delay.

[svgeesus]

Some useful details on the required HTML classes for candidate additions in this specberus issue