Re: [sensors] Future proofing terminology

> All that to say that the reporting frequency is a function of the sampling frequency and not the opposite.

Absolutely agree, and it is reflected in the [abstract operations](https://w3c.github.io/sensors/#abstract-operations). 

The problem as I see it now (and thanks for pointing it out!) is an unfortunate name and definition of the [Sensor.requestedReportingFrequency](https://w3c.github.io/sensors/#dom-sensor-requestedreportingfrequency-slot) internal slot. Now it might give a wrong impression that it is only to define [reporting frequency](https://w3c.github.io/sensors/#reporting-frequency) , actually this slot stores the `frequency` option and its value is used for these two things:
1) (indirectly) set the [requested sampling frequency](https://w3c.github.io/sensors/#requested-sampling-frequency) for the associated platform sensor.
2) set the [reporting frequency](https://w3c.github.io/sensors/#reporting-frequency)  for the given Sensor object (in practice it sets the upper limit because `reporting frequency` is always capped to `sampling frequency`).

I will rename the slot to `frequency` (so that it reflects the ctor option name) and provide a better description to avoid this confusion.

-- 
GitHub Notification of comment by pozdnyakov
Please view or discuss this issue at https://github.com/w3c/sensors/issues/294#issuecomment-333092609 using your GitHub account