Publish as FPWD

[marcoscaceres]

The spec now contains some pretty significant updates since 2016:

• Now Controlled by feature policy - Add feature policy support #41
• Fixed confusion around callback interfaces not being an EventHandler fix: callbacks are not EventHandlers #39
• Only expose the API in SecureContexts
• Renamed the interfaces and dictionaries + removal of NoInterfaceObject + [SameObject] annotation on geolocation attribute Rename NavigatorGeolocation* interfaces to Geolocation* #23

@plehegar, @anssiko, I think it's worth republishing new Recommendation. WDYT?

[anssiko]

@plehegar, @anssiko, I think it's worth republishing new Recommendation. WDYT?

I agree. We have now addressed all the known open issues and the spec has been hardened for security and privacy in line with the group's maintenance commitment after taking the spec over from the now-defunct Geolocation WG. To my understanding, all the major implementations agree with the spec, but implementers please chime in if that's not the case.

@plehegar what is the path of least resistance (read: least make work) to publish a new Recommendation? Should we wait for the Process 2020 to be operational?

Cc @reillyeon for the co-chair perspective.

Cc @cdumez for WebKit.

[reillyeon]

I agree that a new Recommendation is warranted.

[plehegar]

TL;DR: use Process 2019 even if it's not ideal.

Long version:

Current choices are listed in the next steps.

Do you consider the part "Controlled by feature policy" to be a new feature? My guess is that it isn't, since it does not add new functionality.

If I'm correct, the path with Process 2019 would be to Publish a Candidate Recommendation with substantive changes (but no new features).

This would put you to publish the amended REC in September 2020.

If you pick the Proceess 2020 route, the current prediction is September 1 for it to become effective. You would first have to move your charter to P2020. That's around 30 days. This mean you could republish the original REC, with the changes appearing as proposed corrections (see Revising a Recommendation: Substantive Changes) in October 2020. You can then republish the REC, with the proposed changes folded in, around January 2021 (time is eaten by the Call for Exclusion started in October).

Now, the pros and cons:

• P2019 path gives the full updated REC in September, but forces you to publish a CR and a PR to get there.
• P2020 path doesn't force you to publish a CR and a PR but, because P2020 isn't effective yet and your charter doesn use it, you stuck until October, at the earliest.

So, in summary, if you can bear the thought of going through a CR first, I recommend the path P2019 since it gets you to the updated REC sooner.

[marcoscaceres]

I don't mind going through CR again.

[xfq]

I agree with @plehegar that we should publish a Candidate Recommendation with substantive changes (but no new features), if the feature policy support is not considered a new feature.

We also need wide review of the changes before the CR transition.

[marcoscaceres]

Ok, let me know if there is anything I can do to help!

[plehegar]

@anssiko , if you concur, it would be nice to have some kind of group decision to point to for this, and then @xfq can do the paper work.

[anssiko]

@plehegar CfC to publish Geolocation API Amended Recommendation - review by 18 June 2020

[anssiko]

@xfq CfC passed, please feel free to proceed with the paper work.

[xfq]

Some information for myself:

New normative references since the last REC:

• [FEATURE-POLICY]
• [HTML]
• [RFC8174]
• [secure-contexts]
• [url]

Test suite: https://github.com/web-platform-tests/wpt/tree/master/geolocation-API

Preliminary implementation report: https://wpt.fyi/results/geolocation-API?label=experimental&label=master&aligned

CR exit criteria: two interoperable deployed implementations of each feature

Wide review: #43

[marcoscaceres]

@xfq, #68 adds [Permissions API] as a dep.

[marcoscaceres]

Given that we are operating under the new charter + 2020 Process, I wonder if we should revisit the publication options? We are no longer blocked on using the 2020 Process, so...

[anssiko]

For discussion at https://www.w3.org/events/meetings/a8a1448f-049b-468e-8b45-8eae6b8e75be#agenda

[marcoscaceres]

Awesome! thanks @anssiko. I'll chat to @plehegar in the meantime to get a better understanding of our options to bring to the meeting.

[marcoscaceres]

Hey Folks, @plehegar met this week to chat about the path forward. We looked at the requirements from the Process 2020 and, because we've added new features to the spec, we need to publish a FPWD... which turns out to be a great thing because it means we can significantly modernize the spec, then (relatively) quickly move it to be a "living standard".

So, basically, this will be the plan:

• rewrite the spec, modernizing it to use Infra, etc.
• update the spec to deal with the visibility issue.

We can publish a FPWD whenever we like. Ideally we will do that straight after our meeting in a few weeks - which will give me time to make the above changes. After FPWD, @plehegar suggested we wait one month before going to CR. We can sit on CR until we get browser alignment on the page visibility issue (there are some web compat issues, so we need to decide which model is best and then figure out which engine needs updating). Alternatively, we move quickly to REC, then republish an updated REC to fix the visibility issue ~6 months down the line.

If it's ok with everyone, I'd like to "officially" become Editor of this spec. I'd also be keen to have someone be a co-editor, to also edit or help review PRs (maybe someone new who hasn't edited before - preferably from an underrepresented community in our working group). Any taker to be my co-pilot?

[marcoscaceres]

In prep for FPWD:

must record the group’s decision to request advancement.

https://www.w3.org/2021/04/07-dap-minutes.html#r04

must obtain Director approval.

@xfq, I can't recall the name of the repo where to file the request :( Could you assist me with this?

must publicly document all new features (class 4 changes) to the technical report since the previous publication.

https://w3c.github.io/geolocation-api/#changes-since-last-publication

must publicly document if other substantive changes (class 3 changes) have been made, and should document the details of such changes.

https://w3c.github.io/geolocation-api/#changes-since-last-publication

should publicly document if editorial changes have been made, and may document the details of such changes.

https://github.com/w3c/geolocation-api/commits/gh-pages

must formally address all issues raised about the document since the previous maturity level.

All issues have been responded to in:
https://github.com/w3c/geolocation-api/issues

must provide public documentation of any Formal Objections.

None.

should report which, if any, of the Working Group's requirements for this document have changed since the previous step.

None.

should report any changes in dependencies with other groups.

None.

should provide information about implementations known to the Working Group.

Implementation in Blink, WebKit, and Gecko.

[xfq]

@xfq, I can't recall the name of the repo where to file the request :( Could you assist me with this?

It's https://github.com/w3c/transitions/issues and I am happy to help file the issue (actually I have created a test FPWD snapshot), but before filing the transition request, I found the following paragraph in our charter:

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email and/or web-based survey), with a response period from 5 to 10 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

It looks like we only have a CfC for publishing this spec as an Amended Recommendation, but not for FPWD, so we probably need to issue a new CfC first...

[marcoscaceres]

It looks like we only have a CfC for publishing this spec as an Amended Recommendation, but not for FPWD, so we probably need to issue a new CfC first...

Agree. @anssiko, do you want to "replay": https://lists.w3.org/Archives/Public/public-device-apis/2020Jun/0006.html

In the meantime, it would be great if someone from the group could step up and review the spec from start to finish. I basically rewrote the whole thing, so there are bound to be typos or potentially other issues.

[anssiko]

FYI: CfC to publish Geolocation API First Public Working Draft - review by 26 April 2021

[anssiko]

The CfC passed. @xfq please proceed with the publication.

[xfq]

Since the shortname of the current REC is geolocation-API and an FPWD is considered a new document, we cannot reuse the same shortname, so the document has to be published under a different shortname.

We have two options:

• either go with geolocation-API-2 and it's approved already
• or switch to geolocation but then, @plehegar needs to approve it

[marcoscaceres]

"geolocation" is my preference... versions/levels don't make any sense.

[reillyeon]

Having "geolocation-API" point to the REC and "geolocation" point to the WD sounds confusing. Are there no prior examples we can work from here? I have a slight preference for "geolocation-API-WD". I assume that when we publish another REC version of this specification it will overwrite the current document at "geolocation-API".

[marcoscaceres]

geolocation-API-WD

Having that status in the short name is not a thing.

How it will work is "geolocation-API" will become Superseded Recommendation, and "geolocation" will become the new canonical Recommendation.

[deniak]

I wouldn't recommend using geolocation-API-WD since it's the shortname that will be used to identify the specification even after it reaches CR.
Now, if the new document is published under the shortname geolocation, we could redirect https://www.w3.org/TR/geolocation-API/ to https://www.w3.org/TR/geolocation/.

[reillyeon]

How it will work is "geolocation-API" will become Superseded Recommendation, and "geolocation" will become the new canonical Recommendation.

Does this mean that every time there is a new Recommendation the shortname needs to change or does this only apply because we're switching to a new Process?

[deniak]

Does this mean that every time there is a new Recommendation the shortname needs to change or does this only apply because we're switching to a new Process?

It's actually a mix of things. With the previous process document, you can only revise a REC with non substantive changes. In this case, I understand you are adding new features. That's why @plehegar said you need to publish a FPWD.

The good news is the new process document facilitates that kind of updates to existing RECs so going forward, WGs won't need to publish a FPWD to add new features.

[anssiko]

Redirect from https://www.w3.org/TR/geolocation-API/ to https://www.w3.org/TR/geolocation/ solves the REC vs WD confusion so I believe we can settle on ”geolocation” as the shortname.

[xfq]

Published: https://www.w3.org/TR/2021/WD-geolocation-20210527/