From df1dff1b90bc0bd1909801d96e592a856ad74045 Mon Sep 17 00:00:00 2001 From: Raphael Kubo da Costa Date: Fri, 21 Jul 2023 17:02:57 +0200 Subject: [PATCH] Reword the "Sensor Type" section, move permission revocation algorithm Instead of having several paragraphs mixing what a sensor type must or may and algorithms, the "Sensor Type" section now only has two paragraphs and two groups containing what must be defined and what may be defined to make it easier to follow. This also has consequences for the "Extensibility" section, as its "Definition Requirements" subsection used to duplicate some of the contents in "Sensor Type". It now just refers to the latter and provides more details about how some of a sensor type's associated data must be defined in extension specifications. Some data that used to be associated with a sensor type has been removed: - "Associated sensors" were never properly defined and it was not clear that they meant "associated _platform_ sensors". They were only used in the generic sensor permission revocation algorithm, which has been rewritten. - "Permission request algorithm" is a term that has been moved from the Permissions spec to the Requesting Permissions permission in WICG. None of the extension specifications ever defined it. The generic sensor permission revocation algorithm was moved to the "Abstract Operations" section. It has also been merged with the revoke sensor permission algorithm since it was its only caller. There should not be any user-visible effects though: the language was just made more formal by iterating over all Sensor instances belonging to the current realm (like the Web Bluetooth spec does) instead of hand-wavingly gathering all platform sensors (which technically are per-navigable) with the same sensor type. Related to #463. --- index.bs | 97 +++++++++++++++++++++++--------------------------------- 1 file changed, 40 insertions(+), 57 deletions(-) diff --git a/index.bs b/index.bs index efc15c0..b21fbc6 100644 --- a/index.bs +++ b/index.bs @@ -80,6 +80,9 @@ urlPrefix: https://w3c.github.io/geolocation-sensor/; spec: GEOLOCATION-SENSOR urlPrefix: https://w3c.github.io/proximity; spec: PROXIMITY type: dfn text: ProximitySensor; url: proximity-sensor-interface +urlPrefix: https://tc39.github.io/ecma262/; spec: ECMAScript + type: dfn + text: current realm; url: current-realm 
 spec: dom; type:dfn; text:event
@@ -769,44 +772,23 @@ Note: In order to release hardware resources, the user agent can request underly
 
 
Sensor Type

 
-A sensor type has one or more associated
-[=extension sensor interface|extension sensor interfaces=].
-
-A [=sensor type=] has a [=ordered set|set=] of associated sensors.
-
-A [=sensor type=] may have a [=default sensor=].
-
-A [=sensor type=] has a [=set/is empty|nonempty=] [=ordered set|set=] of associated
-[=powerful feature/names=] referred to as sensor permission names.
-
-Note: Multiple [=sensor types=] may share the same [=powerful feature/name=].
-
-A [=sensor type=] has a [=permission revocation algorithm=].
-
-

-
-    To invoke the 
-    generic sensor permission revocation algorithm
-    with [=powerful feature/name=] |permission_name|, run the following steps:
-
-    1.  For each |sensor_type| whose [=sensor permission names|permission names=] [=set/contains=] |permission_name|:
-        1.  [=set/For each=] |sensor| in |sensor_type|'s [=ordered set|set=] of [=associated sensors=],
-            1.  Invoke [=revoke sensor permission=] with |sensor| as argument.
-

-
-A [=sensor type=] has a [=permission request algorithm=].
+A sensor type must have the following associated data:
+- One or more [=extension sensor interfaces=].
+- An [=set/is empty|nonempty=] [=ordered set=] of associated [=powerful feature/name|powerful
+  feature names=] referred to as sensor permission names.
 
-A [=sensor type=] has a [=set/is empty|nonempty=] [=ordered set|set=] of associated
-[=policy-controlled feature=] tokens referred to as sensor feature names.
+  Note: Multiple [=sensor types=] may share the same [=powerful feature/name=].
+- An [=set/is empty|nonempty=] [=ordered set=] of associated [=policy-controlled feature=] tokens
+  referred to as sensor feature names.
+- A [=permission revocation algorithm=].
 
-A [=sensor type=] may have an associated threshold check
-algorithm, which takes as arguments two separate [=sensor readings=] and
-determines if they differ enough to cause a [=platform sensor=]'s [=latest
-reading=] map to be updated.
-
-A [=sensor type=] may have an associated reading quantization
-algorithm, which takes a [=sensor reading=] and returns a less accurate
-[=sensor reading=].
+A [=sensor type=] may have the following associated data:
+- A [=default sensor=].
+- A threshold check algorithm, which takes as arguments two separate [=sensor
+  readings=] and determines if they differ enough to cause a [=platform sensor=]'s [=latest
+  reading=] map to be updated.
+- A reading quantization algorithm, which takes a [=sensor reading=] and returns a
+  less accurate [=sensor reading=].
 
 
Sensor

 
@@ -1353,21 +1335,22 @@ to {{SensorErrorEventInit}}.
         1.  Set |sensor_instance|.{{[[lastEventFiredAt]]}} to null.
 
 
-
Revoke sensor permission

+
Generic Sensor permission revocation algorithm

 
-

+

 
     : input
-    :: |sensor|, a [=platform sensor=].
+    :: |permissionName|, a [=powerful feature/name|powerful feature name=]
     : output
     :: None
 
-    1.  Let |activated_sensors| be |sensor|'s associated [=ordered set|set=] of [=activated sensor objects=].
-    1.  [=set/For each=] |s| of |activated_sensors|,
-        1.  Invoke [=deactivate a sensor object=] with |s| as argument.
-        1.  Let |e| be the result of [=exception/create|creating=]
-            a "{{NotAllowedError!!exception}}" {{DOMException}}.
-        1.  Queue a task to run [=notify error=] with |s| and |e| as arguments.
+    1. For each {{Sensor}} instance |sensor| in the [=current realm=]:
+       1. If |sensor|'s associated [=platform sensor=]'s [=sensor type=]'s [=sensor permission
+          names=] [=set/contains=] |permissionName|:
+          1. Invoke [=deactivate a sensor object=] with |sensor|.
+          1. Let |exception| be the result of [=exception/create|creating=]
+             a "{{NotAllowedError}}" {{DOMException}}.
+          1. Queue a task to run [=notify error=] with |sensor| and |exception|.
 

 
 
Set sensor settings

@@ -2021,8 +2004,10 @@ accuracy or other settings defined in [=extension specifications=].
 
 
Definition Requirements

 
-The following definitions must be specified for
-each [=sensor type=] in [=extension specifications=]:
+[=Extension specifications=] must define all the associated data listed in [[#model-sensor-type]].
+
+This section provides more information about some of the associated data that [=extension
+specifications=] must specify.
 
 -   An extension sensor interface, which is an [=interface=]
     whose [=inherited interfaces=] contains {{Sensor}}.
@@ -2044,20 +2029,18 @@ each [=sensor type=] in [=extension specifications=]:
     [=get value from latest reading=] with this and
     [=attribute=] [=identifier=] as arguments.
 
--   A [=powerful feature/name=], if the [=sensor type=] is not representing
-    [=sensor fusion=] (otherwise, [=powerful feature/names=]
-    associated with the fusion source [=sensor types=] must be used).
+-   If the [=sensor type=] is representing [=sensor fusion=], its [=sensor permission names=] must
+    be those associated with the fusion source [=sensor types=].
 
 An [=extension specification=] may specify the following definitions
-for each [=sensor types=]:
+for each [=sensor type=]:
 
 -   A [=dictionary=] whose [=inherited dictionaries=] contains {{SensorOptions}}.
--   A [=default sensor=]. Generally, devices are equipped with a single [=platform sensor=]
-    of each [=sensor types|type=],
-    so defining a [=default sensor=] should be straightforward.
-    For [=sensor types=] where multiple [=device sensor|sensors=] are common,
-    [=extension specifications=] may choose not to define a [=default sensor=],
-    especially when doing so would not make sense.
+-   A [=default sensor=]. Generally, devices are equipped with a single [=platform sensor=] of each
+    [=sensor types|type=], in which case defining a [=default sensor=] is straightforward. For
+    [=sensor types=] where multiple [=device sensor|sensors=] are common, [=extension
+    specifications=] may choose not to define a [=default sensor=], especially when doing so would
+    not make sense.
 
 
Automation