[meta] Publish Candidate Recommendation

[anssiko]

The Candidate Recommendation (CR) publication of the Presentation API is looming in the horizon. By publishing a CR we:

• signal the group has met its requirements satisfactorily for a new standard,
• ask the entire W3C membership to provide feedback,
• formally collect implementation experience to demonstrate that the specification works in practice.

While we're well on our way to satisfy the CR requirements, there are some things to be completed before we can hit this significant milestone, namely:

• Resolve the open issues we can address before the F2F (thanks @tidoust):
  • Evaluate Presentation API against the Media Accessibility User Requirements spec #162 Evaluate Presentation API against the Media Accessibility User Requirements spec
  • PresentationSession should have stream interfaces! #163 PresentationSession should have stream interfaces!
  • Possibility for a character to be interpreted differently depending on locale #218 Possibility for a character to be interpreted differently depending on locale
  • bufferedAmount property on PresentationConnection #241 bufferedAmount property on PresentationConnection
  • Have the receiving browsing context generate the presentation identifier? #253 Have the receiving browsing context generate the presentation identifier?
  • When is the first presentation connection created in the receiving browsing context? #254 When is the first presentation connection created in the receiving browsing context?
  • Only allow one PresentationAvailability per PresentationRequest #269 Only allow one PresentationAvailability per PresentationRequest
  • PresentationConnectionClosedEventInit.message needs to have a default value #273 PresentationConnectionClosedEventInit.message needs to have a default value
• Resolve the open issues tagged for F2F that likely require F2F discussion:
  • Define behavior of Window and Fullscreen APIs in the presentation browsing context #99 Define behavior of Window and Fullscreen APIs in the presentation browsing context
  • Assess interoperability of Presentation API implementations #153 Assess interoperability of Presentation API implementations
  • Is a new Permission type required for presentation display availability? #255 Is a new Permission type required for presentation display availability?
  • User Data Controls in Web Browsers guidelines #275 User Data Controls in Web Browsers guidelines
  • Add presentation request URL fallback mechanism #311 Add presentation request URL fallback mechanism
  • Clear service worker's persistent storages in a receiving browsing context #318 Clear service worker's persistent storages in a receiving browsing context
• Provide a draft test suite to be able to say we have "document[ed] how adequate implementation experience will be demonstrated". Please get in touch with the Test Facilitator @louaybassbouss to contribute and help.
  • [meta] Presentation API Testing #266 [meta] Presentation API Testing

With continued active participation we're trending toward hitting CR after the May F2F, before the vacation period.

[tidoust]

@anssiko, I agree that #202 (Presentations without communication channel) can be considered a new feature and defered to v2. I updated issue labels accordingly.

Although not explicit in the CR requirements, publication as CR normally implies that known technical issues have been addressed and more generically that the group has solved all issues that could lead to normative changes in the spec. We also need to demonstrate that the specification has undergone wide review.

As such, I would add at least the following issues to the list of issues to be solved before CR:

• Evaluate Presentation API against the Media Accessibility User Requirements spec #162 Evaluate Presentation API against the Media Accessibility User Requirements spec
• PresentationSession should have stream interfaces! #163 PresentationSession should have stream interfaces!
• Possibility for a character to be interpreted differently depending on locale #218 Possibility for a character to be interpreted differently depending on locale
• bufferedAmount property on PresentationConnection #241 bufferedAmount property on PresentationConnection
• Have the receiving browsing context generate the presentation identifier? #253 Have the receiving browsing context generate the presentation identifier?
• When is the first presentation connection created in the receiving browsing context? #254 When is the first presentation connection created in the receiving browsing context?
• Only allow one PresentationAvailability per PresentationRequest #269 Only allow one PresentationAvailability per PresentationRequest
• PresentationConnectionClosedEventInit.message needs to have a default value #273 PresentationConnectionClosedEventInit.message needs to have a default value

Some of these issues may need to be discussed at the F2F, but most of them simply need some sort of "PR" (Pull Request or Proposed Resolution). Essentially, I'd like to propose the same game as in January: let's kill some issues so that the spec may be published as CR shortly after the F2F!

[anssiko]

As suggested by @tidoust, let's apply the proven formula from January to the above issue list.

Anyone is free to pick any issue from the above list, address it by submitting a PR, or by suggesting text in the issue comments to be integrated. The results of this collaborative exercise is to be summed up at the F2F.

[anssiko]

I updated the first comment in this issue to link to the known CR blockers, split in two buckets: (1) issues we think can be addressed before the F2F, and (2) issues that require F2F discussion. Please see:

#276 (comment)

We're making good progress in addressing the first bucket of issues -- contributions from all group participants are welcome!

[anssiko]

Here's the summary of the PROPOSED RESOLUTIONs for the remaining CR blockers we discussed at the F2F.

@mfoltzgoogle I assume you'll update the spec to address the first four issues, and will sync with relevant implementers re #311 feasibility.

@tidoust When should we have a publication ready spec for the CR transition request if we'd like to publish by the end of June, or soon after? I'd like to get the CR out before we enter the seasonally slower summer months.

• Define behavior of Window and Fullscreen APIs in the presentation browsing context #99 Define behavior of Window and Fullscreen APIs in the presentation browsing context
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item16
  • PROPOSED RESOLUTION: No change to the Presentation API, feature would be addressed by the CSS WG if a strong use case motivates it. Open another issue about recommending to add "TV" to the User-Agent string.
• Assess interoperability of Presentation API implementations #153 Assess interoperability of Presentation API implementations
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item15
  • ACTION:
    • advance with the CG chartering https://github.com/webscreens/cg-charter/ to incubate protocol-level interop
    • spun off an issue Add presentation request URL fallback mechanism #311 impacting API interop
• Is a new Permission type required for presentation display availability? #255 Is a new Permission type required for presentation display availability?
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item13
  • PROPOSED RESOLUTION: no new permission type required
• User Data Controls in Web Browsers guidelines #275 User Data Controls in Web Browsers guidelines
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item14
  • PROPOSED RESOLUTION: complete the clear site data steps in the spec (add AppCache, Service Workers) and add non-normative note referencing TAG document for more complete list, add note clarifying this is not about defining private mode
• Clear service worker's persistent storages in a receiving browsing context #318 Clear service worker's persistent storages in a receiving browsing context (spun off from User Data Controls in Web Browsers guidelines #275)
  • (PROPOSED RESOLUTION): Specify how the service worker’s persistent storages are cleared in the receiving browsing context when creating and closing a receiving browsing context in accordance with the User Data Controls in Web Browsers guidelines (spun off from User Data Controls in Web Browsers guidelines #275)
• Add presentation request URL fallback mechanism #311 Add presentation request URL fallback mechanism
  • F2F minutes: https://www.w3.org/2016/05/25-webscreens-minutes.html#item03
  • PROPOSED RESOLUTION: Add a fallback mechanism by adding a new constructor on PresentationRequest that takes an Array of DOMString, and by exposing the presented URL in an "url" attribute on PresentationConnection, pending feedback from implementers that this is doable.

[tidoust]

@anssiko

When should we have a publication ready spec for the CR transition request if we'd like to publish by the end of June, or soon after?

Before the spec may be published as CR, we need to organize a transition call with the Director (at least one week) and work with Comm team on the transition announcement (a couple of days). That would suggest Friday 24 June for a publication beginning of July, and thus Monday 13 June to issue the call for consensus.

[anssiko]

Current status: good progress, two CR blockers remain: #275 (have a PR #308) and #311 (no PR to review yet).

We aim to send out a CfC soon, but not today.

[anssiko]

CfC: Publish CR of Presentation API, review by 27 June

[anssiko]

Presentation API CR publication status update:

In the Call for Consensus sent 14 June we set the following condition for the CR publication:

Please note the group will resolve the issues #311 (URL fallback mechanism) and #318 (clear service worker's persistent storage) per agreement at the F2F and include these changes in the CR.

This condition is not yet met, thus we may want extend the CfC slightly to ensure appropriate review time.

All - this is a great opportunity to help close these two remaining CR blockers so we can advance the spec to CR. All contributions welcome!

[anssiko]

Status update for the remaining CR blockers:

• Add presentation request URL fallback mechanism #311 fixed with Updates PresentationRequest to take multiple URLs #316 (thanks @mfoltzgoogle)
• Clear service worker's persistent storages in a receiving browsing context #318 has a proposed fix Addresses Issue #318 #320 (thanks @tomoyukilabs) pending review and integration into the spec

Given #316 had a review time of 14 days with no major concerns, and there's a proposed fix for #318 (smaller interoperability impact), the initial CfC holds and after landing #320 we proceed with the original plan to publish CR earliest beginning of July.

[anssiko]

Also the draft test suite (tracked in #266) is coming together just in time for the CR publication (thanks @louaybassbouss et al.).

[anssiko]

All the CR blockers have now been addressed. Thank you for your contributions everyone, with special thanks to the editor @mfoltzgoogle who has reflected the group's consensus into the spec language.

I'm happy that (once again) we were able to sprint and get the spec ready for publication in time. We're now ready to advance with the CR publication as planned.

[markafoltz]

@anssiko I filed an issue today (#324) that may impact this timeline. Do you want to wait for a spec change to land for that first?

[tidoust]

@mfoltzgoogle The version of the spec that is to be published as CR is somewhat frozen at this stage. It was reviewed by the Director and publication as Candidate Recommendation is scheduled for tomorrow (Thursday). I would suggest that we go ahead with the CR publication as-is, and address #324 and subsequent issues in the Editor's Draft.

From a process perspective, changing the name of an interface is obviously a normative change which would in theory require another publication as CR. In practice, we can argue that changing the name of such an event interface is benign (I think that most apps will simply listen to the close event and won't ever check the class of the event they get), so this change should not delay the progress of the spec along the Recommendation track.

[anssiko]

I second @tidoust.

[markafoltz]

Yes, Issue #324 naming cleanup and not a semantic change. If it shouldn't block CR then let's not derail the process underway.

[anssiko]

Candidate Recommendation published:
https://www.w3.org/TR/2016/CR-presentation-api-20160714/