Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update status of this document #61

Merged
merged 1 commit into from
Jun 17, 2024
Merged

Update status of this document #61

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,19 @@ Editor: Thomas Steiner 44965, Google Inc., https://google.com/
Editor: Marijn Kruisselbrink 72440, Google Inc., https://google.com/
Group: dap
Status Text:
<strong>This specification presents a [[#use-cases-categorization]] informed by feedback
and requests from the wider community, end users and web developers. These use cases
welcome further review from the wider web community to ensure the documented use case set
satisfies the needs of all stakeholders and provides appropriate abstractions for these capabilities.
Review and feedback is sought after in particular for the new [[#use-cases-background-continuous]]
and [[#use-cases-background-geofence]] use case categories. All feedback, including
contributions for new informative use cases and other considerations,
is welcome via <a href="https://github.com/w3c/geolocation-sensor/issues">GitHub issues</a>.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
is welcome via <a href="https://github.com/w3c/geolocation-sensor/issues">GitHub issues</a>.
is welcome via <a href="[REPOSITORYURL]/issues">GitHub issues</a>.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @reillyeon. Addressed your suggestion in an update, also updated the commit message.

Could you open a new issue linking to the proposal from 2014 you mentioned?

I'd like to link to that issue from this status text as to raise awareness of options that have been considered and to invite feedback and comments from the web community on that proposal.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like spec-prod validator does not like [REPOSITORYURL] text macro inside href, CI error:

error: Bad value “[REPOSITORYURL]/issues” for attribute “href” on element “a”: Illegal character in path segment: “[” is not allowed.

Local build was fine. May need to revert back to the plain old URL unless some Bikeshed expert tells me otherwise.

Copy link
Contributor

@himorin himorin Jun 4, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't define repository in macro, so add repository line (with text macro: REPOSITORY w3c/geolocation-sensor etc.)

(fixed)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(wrong again...) text macro will be created following Repository: line, and should be created automatically if bikeshed runs via ghaction... hrm.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR updated. The rendered version will have a very visible issue block on top of the API section pointing to that issue. The status text links to the API section too setting expectations with regard to changes expected.

Also fixed the text macro, thanks @himorin for filing an issue for that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is fine but please remove the "Fix #60" comment in the description as this does not resolve the issue raised there. To be clear, I think there are two paths forward for resolving that issue. Either,

  1. Mark this specification as Obsolete and start a new specification tailored to the background/geofencing use cases.
  2. Get consensus from working group participants that the API presented in the current draft is something that should be pursued as a replacement for the existing Geolocation API.

I recommend (1). I don't foresee (2) being possible because there has been no interest for many years in implementing this API.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for (1)!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@reillyeon thanks for the suggestions. I removed the left-over "Fix" from the comment. PTAL and merge at will.

Some considerations:

  • Background/geofencing use cases and path forward will be an excellent TPAC discussion.
  • If the WG finds out relevant foreground use cases are addressed by the old Geolocation API, this new API could be rescoped to address background/geofencing use cases.
  • For background/geofencing API shape considerations, @mkruisselbrink's proposals referenced in Background geofencing #62 are (still) good input and this PR makes those proposals prominent and notes the API is expected to change. (Good proposals age like fine wine! 🍷)

A process-related clarification for option (1):

Given this spec is a Working Draft, and given (1) proposes a narrower scope, the WG only needs to decide to publish an updated Working Draft with foreground functionality removed without any heavy-handed mechanisms beyond that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, we can just modify the Working Draft.


In line with the expectations of the Working Draft maturity stage,
the normative [[#api]] definition may change based on stakeholders' feedback,
implementation experience, security and privacy, and other considerations.</strong>

The Devices and Sensors Working Group will perform a round of self-review and
revisions on the security and privacy aspects of the API before
requesting horizontal review. Existing security and privacy issues can
Expand Down Expand Up @@ -147,6 +160,8 @@ Note: Consider adding a visual of the standard coordinate system for the Earth.
API {#api}
===

Issue(62):

The GeolocationSensor Interface {#geolocationsensor-interface}
-------------------------------

Expand Down
Loading