汎用センサー API — Generic Sensor API

4.1. ~privacy／~security脅威の型

4.2. 軽減~策

この節では、 この仕様の規範的な各~節にて指定される軽減~策のうち一部について， 高levelな呈示【！＊】を与える。 ◎ This section gives a high-level presentation of some of the mitigation strategies specified in the normative sections of this specification.

4.3. 事例~別に適用される軽減~策

各`~sensor型$は、 個別に査定される必要がある — ［ それが可能化する各~利用事例, それの特定0の脅威~profile ］を織り込んで。 下に与える軽減~策のうち一部は、 ある種の~sensor用には効果的になる一方で， ある種の利用事例を邪魔する／まるごと防止するかもしれない。 ◎ Each sensor type will need to be assessed individually, taking into account the use cases it enables and its particular threat profile. While some of the below mitigation strategies are effective for certain sensors, they might also hinder or altogether prevent certain use cases.

注記： これらの軽減~策は、 定常的にも一時的にも適用できる — 例えば、 利用者が特定の動作を遂げているとき／ 脅威の~levelを増幅することが既知な他の~APIが利用-中にあるとき, 等々。 ◎ Note: These mitigation strategies can be applied constantly or temporarily, for example when the user is carrying out specific actions, when other APIs which are known to amplify the level of the threat are in use, etc.

5.1. ~sensor

用語 `~device~sensor@ （ `device sensor^en ）は、 ~deviceの下層の物理的~sensor~instanceを指す。 ◎ The term device sensor refers to a device’s underlying physical sensor instance.

`~device~sensor$は、 物理量を測定して，対応する `~sensor読取り@ （ `sensor reading^en ）を供する — それは、 環境についての情報の~sourceである。 ◎ A device sensor measures a physical quantities and provides a corresponding sensor reading which is a source of information about the environment.

各`~sensor読取り$は、 `~device~sensor$が［ `読取り時刻印@ （ `reading timestamp^en ）と呼ばれる，各~測定-回の時刻 ］に測定した物理量の値たちから構成される。 ◎ Each sensor reading is composed of the values of the physical quantity measured by the device sensor at time tn which is called the reading timestamp.

`~device~sensor$が空間的な測定を遂行する場合（例：加速度, 角速度）、 `~device~sensor$の`~sensor読取り$用の基準~frameを表現する `局所~座標系@ （ `local coordinate system^en ）内に解決するモノトスル。 そのような`~sensor読取り$を供する`~device~sensor$は、 `空間的~sensor@ （ `spatial sensor^en ）と称される。 ◎ If the device sensor performs a spatial measurement (e.g. acceleration, angular velocity), it must be resolved in a local coordinate system that represents a reference frame for the device sensor's sensor readings. A device sensor that provides such sensor readings is referred to as spatial sensor.

`空間的~sensor$は、 同時的な測定を遂行できる直交な軸の本数に依存して，［ 単軸（ `uniaxial^en ）, 二軸（ `biaxial^en ）, 三軸（ `triaxial^en ） ］いずれにもなり得る。 ◎ A spatial sensor can be uniaxial, biaxial, or triaxial, depending on the number of orthogonal axes in which it can perform simultaneous measurements.

~scalar物理量（例：温度）は、 解決~用の`局所~座標系$を要求しない。 ◎ Scalar physical quantities (e.g. temperature) do not require a local coordinate system for resolution.

通常は携帯~deviceで利用される`局所~座標系$は、 ~Cartesian座標系であり，~deviceの~screenに相対的に定義される , その ~X軸, ~Y軸は~screenの各 次元に平行になり，~Z軸は~screen面に垂直になる。 ◎ The local coordinate system normally used in a mobile device is a Cartesian coordinate system, which is defined relative to the device’s screen, so that X and Y axes are parallel to the screen dimentions and Z axis is perpendicular to the screen surface.

用語 `~platform~sensor@ （ `platform sensor^en ）は、 ~UAが［ 1 個~以上の`~device~sensor$を出自にする単独の`~sensor型$ ］用に`~sensor読取り$を得するためにヤリトリできるような，~platform~interfaceを指す。 ◎ The term platform sensor refers to platform interfaces, with which the user agent interacts to obtain sensor readings for a single sensor type originated from one or more device sensors.

`~platform~sensor$は、 下層の~platformにより定義されることもあれば （例：~native~sensor~framework内で）， ~UAにより定義されることもある — `~device~sensor$への直な~accessを有するならば。 ◎ Platform sensor can be defined by the underlying platform (e.g. in a native sensors framework) or by the user agent, if it has a direct access to device sensor.

実装の視点からは、 `~platform~sensor$は，対応する`~device~sensor$用の~software~proxyとして扱える。 下層の~platformが~supportするならば、 複数の`~platform~sensor$が同じ`~device~sensor$に同時的にヤリトリする可能性もある。 ◎ From the implementation perspective platform sensor can be treated as a software proxy for the corresponding device sensor. It is possible to have multiple platform sensors simultaneously interacting with the same device sensor if the underlying platform suppports it.

単純な事例では，`~platform~sensor$は単独の`~device~sensor$に対応するが、 供された`~sensor読取り$が~software内で遂行された`~sensor融合$の産物である場合，`~platform~sensor$は［ `~sensor融合$の処理nに孕まれる`~device~sensor$の集合 ］に対応する。 ◎ In simple cases, a platform sensor corresponds to a single device sensor, but if the provided sensor readings are a product of sensor fusion performed in software, the platform sensor corresponds to a set of device sensors involved in the sensor fusion process.

`~sensor読取り$と［ それに対応する，測定される物理量 ］との不一致は、 `較正@ （ `calibration^en ）を通して正される — この不一致は、 製造~時に起こり得る。 一部の~sensorは、 未知な不一致を補償するため，動的な較正を要求し得る。 ◎ Discrepancies between a sensor reading and the corresponding physical quantity being measured are corrected through calibration that can happen at manufacturing time. Some sensors can require dynamic calibration to compensate unknown discrepancies.

注記： `~sensor融合$を通して作成される`~platform~sensor$は、 ~virtual~sensor, あるいは合成な~sensorとも呼ばれる。 しかしながら，実用的には、 この仕様は，それらを区別しない。 ◎ Note: Platform sensors created through sensor fusion are sometimes called virtual or synthetic sensors. However, the specification doesn’t make any practical distinction between them.

5.2. ~sensor型

測定される物理量は、 `~sensor型$ごとに異なる — 温度, 気圧, 心拍数, 光度など。 ◎ Different sensor types measure different physical quantities such as temperature, air pressure, heart-rate, or luminosity.

この仕様の目的においては、 各`~sensor型$は［ `高level$, `低level$ ］の 2 つに大別される： ◎ For the purpose of this specification we distinguish between high-level and low-level sensor types.

• ~sensorのうち，その実装により特徴付けられる`~sensor型$は、【！＊】 `低level@ （ `low-level^en ）な~sensorと称される。 例えば， `Gyroscope^I は`低level$な`~sensor型$である。 ◎ Sensor types which are characterized by their implementation are referred to as low-level sensors. For example a Gyroscope is a low-level sensor type.
• ~sensorのうち，その`~sensor読取り$の名前を継ぐもの【！＊】は、 その実装に関わらず， `高level@ （ `high-level^en ）な~sensorであるとされる。 一例として，地理所在~sensorは利用者の所在についての情報を供するが、 この~dataが得される精確な手段は，目的を以って不透明なままにされており （それは、［ ~GPS集積回路, ~network基地局三角測量, ~wifi~network, 等々，あるいはこれら任意の組合n ］のどれからも得られ得る）、 実装に特有な様々な経験則に依存する。 `高level$な~sensorは、 一般に，`低level$な~sensorに何らかの~algoを適用した結果【！fruits】 — 例えば，歩数計は~gyroscopeの出力のみを利用して築ける — であるか，`~sensor融合$のそれである。 ◎ Sensors named after their readings, regardless of the implementation, are said to be high-level sensors. For instance, geolocation sensors provide information about the user’s location, but the precise means by which this data is obtained is purposefully left opaque (it could come from a GPS chip, network cell triangulation, wifi networks, etc. or any combination of the above) and depends on various, implementation-specific heuristics. High-level sensors are generally the fruits of applying algorithms to low-level sensors—for example, a pedometer can be built using only the output of a gyroscope—or of sensor fusion.

とは言え、 `~sensor型$における［ `高level$, `低level$ ］の区別は，いくぶん恣意的であり、 この 2 つの間の線引きは，ぼやけていることが多い。 一例として，気圧を測定する気圧計は、 それが［ 圧抵抗圧力~sensorと温度~sensorが成す`~sensor融合$ ］の産物であっても，最も共通的な目的においては`低level$と見なされる — それを構成する~sensorを公開しても実用的な目的は果たさないので （圧電~sensorの温度を気にする者は居なかろう）。 気圧高度計も、 おそらく同じ分類に入る。 一方，構造不明な高度計は、 その~dataを気圧計からも~GPS信号からも取得することがあり、 明瞭に，`高level$な`~sensor型$に分類されることになる。 ◎ That said, the distinction between high-level and low-level sensor types is somewhat arbitrary and the line between the two is often blurred. For instance, a barometer, which measures air pressure, would be considered low-level for most common purposes, even though it is the product of the sensor fusion of resistive piezo-electric pressure and temperature sensors. Exposing the sensors that compose it would serve no practical purpose; who cares about the temperature of a piezo-electric sensor? A pressure-altimeter would probably fall in the same category, while a nondescript altimeter—which could get its data from either a barometer or a GPS signal—would clearly be categorized as a high-level sensor type.

この区別は，いくぶんぼやけているので、 この仕様に対する拡張 （ `§ 拡張能＠#extensibility$を見よ） は、対象になる`~sensor型$用に，その専門分野に特有な［ `高level$, `低level$ ］~sensorの定義を供することが奨励される。 ◎ Because the distinction is somewhat blurry, extensions to this specification (see § 10 Extensibility) are encouraged to provide domain-specific definitions of high-level and low-level sensors for the given sensor types they are targeting.

相異なる`~sensor型$からの`~sensor読取り$は、 `~sensor融合@ （ `sensor fusion^en ）と呼ばれる処理nを通して，一緒に結合され得る。 この処理nは、 `高level$な, または より正確aな~dataを供する （待時間が増える~costと引き換えになることが多い）。 例えば，［ 三軸からなる磁力計の`~sensor読取り$ ］は、［ そのための正しい軸受を供する，加速度計の`~sensor読取り$ ］と結合される必要がある。 ◎ Sensor readings from different sensor types can be combined together through a process called sensor fusion. This process provides higher-level or more accurate data (often at the cost of increased latency). For example, the readings of a triaxial magnetometer needs to be combined with the readings of an accelerometer to provide a correct bearing.

~sensorには、［ `~smart~sensor@ （ `smart sensor^en ）／ ~sensor~hub （ `sensor hub^en ） ］と呼ばれる［ ~hardware~levelで`較正$と`~sensor融合$を遂げる，組込みの算出-資源 ］を備えるものもある。 それは、 処理nに割かれる~CPU資源を~~節約し, ~battery消費を抑える。 ◎ Smart sensors and sensor hubs have built-in compute resources which allow them to carry out calibration and sensor fusion at the hardware level, freeing up CPU resources and lowering battery consumption in the process.

`~sensor融合$は、［ ~hardware~levelでは遂行し得ない／~appに特有な`~sensor融合$~algoが要求される ］場合には，~software内で遂げられることもある。 ◎ Sensor fusion can also be carried out in software if it cannot be performed at the hardware level or if an application-specific fusion algorithm is required.

5.3. 既定の~sensor

汎用~sensor~APIは、 最も共通的な利用事例を単直にするよう設計されている — より複階的な利用事例も可能化しつつ。 ◎ The Generic Sensor API is designed to make the most common use cases straightforward while still enabling more complex use cases.

今日にて配備されている ほとんどの~deviceは、 同じ`~sensor型$の`~sensor読取り$を供する複数個の`~device~sensor$を備えてはいない。 複数個の類似な`~device~sensor$を要求する利用事例は稀であり、 一般に，特定の`~sensor型$ — 2-in-1【一台二役】~laptop内の複数の加速度計など — に限られる。 ◎ Most of devices deployed today do not carry more than one device sensor providing sensor readings of the same type. The use cases which require a set of similar device sensors are rare and generally limited to specific sensor types, such as multiple accelerometers in 2-in-1 laptops.

したがって，~deviceの既定の（かつ一意になることが多い）`~device~sensor$とヤリトリするのを容易にするため、 この~APIは，各`~sensor型$に対し，単純に対応する［ `Sensor$I の下位class ］を~instance化する。 ◎ The API therefore makes it easy to interact with the device’s default (and often unique) sensor for each type simply by instantiating the corresponding Sensor subclass.

~~実際，［ 所与の`~sensor型$の`~device~sensor$のうち，特定0の一つを識別する ］ような，特有な情報が伴われない下では、 ~UAが `既定の~sensor@ （ `default sensor^en ）を選ぶことになる。 ◎ Indeed, without specific information identifying a particular sensor of a given type, the default sensor is chosen by the user agent.

下層の~platformが`既定の~sensor$を見出す~interfaceを供する場合、 ~UAは，~platformから提供された~sensorを選ぶモノトスル。 他の場合、 ~UA自身が［ ~device上に在る`~device~sensor$のうち，どれが`既定の~sensor$になるか ］を定義する。 ◎ If the underlying platform provides an interface to find the default sensor, the user agent must choose the sensor offered by the platform, otherwise the user agent itself defines which of the sensors present on the device is the default sensor.

let %sensor = new Accelerometer({ frequency: 30 });

%sensor.onreading = () => { ... }
%sensor.start();

注記： この仕様に対する拡張は、 `既定の~sensor$を定義しないことにしてもヨイ — そうしてもイミを成さないならば。 例えば，`~sensor型$ `geolocation^l （地理所在）用の既定の`~device~sensor$を明示的に定義しても，イミを成さない — その~interfaceの実装は、 複数の~backendを利用できるので。 ◎ Note: Extensions to this specification may choose not to define a default sensor when doing so wouldn’t make sense. For example, it does not make sense to explicitly define a default sensor for geolocation sensor type as the implementation of its interface can use multiple backends.

同じ~device上で，同じ`~sensor型$に対応する複数の`~device~sensor$が共存し得る事例では、 拡張~仕様は，それぞれを一意に識別する仕方を定義する必要がある。 ◎ In cases where multiple device sensors corresponding to the same type may coexist on the same device, specification extension will have to define ways to uniquely identify each one.

var %sensor = new DirectTirePressureSensor(
   { position: "rear", side: "left" }
);
%sensor.onreading = _ => console.log(%sensor.pressure);
%sensor.start();

5.4. 標本化~frequency, 報告ng~frequency

この仕様の目的においては、 `~platform~sensor$の `標本化~frequency@ （ `sampling frequency^en ）は， `~platform~sensor$が下層の`~device~sensor$から`~sensor読取り$を得する~frequencyとして定義される。 そのような`~sensor読取り$が得される仕方は、 `実装定義$とする。 ◎ For the purpose of this specification, a platform sensor's sampling frequency is defined as a frequency at which a platform sensor obtains sensor readings from the underlying device sensor. The way such sensor readings are obtained is implementation-defined.

`~platform~sensor$の`標本化~frequency$は、 下層の`~device~sensor$の実際の標本化~rateに対応するとは限らず， この仕様の目的においては不透明である。 ◎ The platform sensor's sampling frequency may not correspond to the device sensor's actual sampling rate, which, for the purpose of this specification, is opaque.

注記： ［ `~sensor読取り$用の~system~levelの~API ］および［ 当の~sensor自身に対する下層の~hardware~interface ］は、 ~polling用にも~event用にも築かれ得る。 ~pollingに基づく`~device~sensor$用には、 `~platform~sensor$の`標本化~frequency$は，［ ~system／~hardware ］から新たな読取りが要請される~rateになる。 ~eventに基づく`~device~sensor$用には、 `~platform~sensor$が，要請された標本化~frequencyを［ ~system／~hardware ］に供する — ~eventたちは、 その~frequency以下で生成される。 ~eventは、 ~sensor読取りが変化しなかった場合には，生成されないこともある。 ◎ Note: System-level APIs for sensor readings and the underlying hardware interface to the sensors themselves may be built for polling or events. For a polling-based device sensor, the platform sensor's sampling frequency would be the rate at which a new reading is requested from the system or hardware. For an event-based device sensor, a platform sensor provides a requested sampling frequency to the system or hardware, and events are generated at that frequency or below. Events may not be generated if the sensor reading has not changed.

`~device~sensor$は、 自身が`~platform~sensor$から受容できる標本化~frequencyの限界域を［ `最小~標本化~frequency@dV ／ `最大~標本化~frequency@dV ］の形でを供してもヨイ — 指定されない場合、［ 0 ／ 無限大 ］をとるとする†。 `~platform~sensor$の`標本化~frequency$は、 下層の`~device~sensor$の［ `最小~標本化~frequency$dV以上, `最大~標本化~frequency$dV以下 ］になるモノトスル。 ◎ A device sensor may provide bounds for the sampling frequency value it can accept from a platform sensor in the form of a minimum sampling frequency and a maximum sampling frequency. A platform sensor's sampling frequency must not be less than the device sensor's minimum sampling frequency or greater than its maximum sampling frequency.

【† これら “既定の” 値は、 他所の記述を簡素化するための，この訳による追加。 】

`~platform~sensor$ %~sensor の`標本化~frequency$は、［ %~sensor にて`作動化された~sensor~obj群$を成す各`~item$が供する `frequency$sl ］に基づいて決定される。 この計算は，`実装定義$であるが、 その結果は，次の両者により設定される限界域の中に入るモノトスル： ◎ A platform sensor's sampling frequency is determined based on the provided [[frequency]] of the items in its set of activated sensor objects. The calculation is implementation-defined, but the outcome value must lie within the bounds set by＼

• %~sensor が`属する~sensor型$の［ `最小~標本化~frequency$, `最大~標本化~frequency$ ］ ◎ the platform sensor's sensor type's minimum and maximum sampling frequencies and＼
• %~sensor の下層の`~device~sensor$の［ `最小~標本化~frequency$dV, `最大~標本化~frequency$dV ］ ◎ its device sensor's minimum and maximum sampling frequencies.

注記： 例えば，~UAは、 `標本化~frequency$を［ 供された各 `frequency$sl が成す集合の `Least Common Denominator (LCD)^en 【！最小公分母】 ］を［ 下層の~platformにより定義される`標本化~frequency$の限界域 ］で切り詰めた結果として見積もってもよい。 ◎ Note: For example, the user agent may estimate the sampling frequency as a Least Common Denominator (LCD) for a set of provided [[frequency]] capped by sampling frequency bounds defined by the underlying platform.

具象-【~sensorに対応する】 `Sensor$I ~obj用の `報告ng~frequency@ （ `reporting frequency^en ）は、 この~objに向けて `reading$et ~eventが`発火され$る~frequencyとして定義される。 ◎ The reporting frequency for a concrete Sensor object is defined as a frequency at which the "reading" event is fired at this object.

`Sensor$I ~obj %~sensor は、 ~UAが下層の~platformから新たな`~sensor読取り$を得するよりも高い~rateでは， それらに~accessし得ない。 したがって， %~sensor の`報告ng~frequency$は： ◎ A Sensor object cannot access new readings at a higher rate than the user agent obtains them from the underlying platform, therefore the reporting frequency＼

• %~sensor に結付けられた`~platform~sensor$ %~platform~sensor の`標本化~frequency$を — その結果，その下層の（指定されたならば）`~device~sensor$の`最大~標本化~frequency$dVも — 決して超過しない。 ◎ can never exceed a platform sensor's sampling frequency, which in turn can never exceed a device sensor's maximum sampling frequency (when specified).

• 次に挙げる事例などにおいては、 %~sensor の `frequency$sl と相違する： ◎ The reporting frequency differs from the Sensor's [[frequency]] in cases such as:

  • 要請された `frequency$sl は、 次が返す限界域の外側にある ⇒ `~platform~sensorの標本化~限界域を取得する$( %~platform~sensor ) ◎ the requested [[frequency]] lies outside the bounds returned by invoking get a platform sensor’s sampling bounds with Sensor's associated platform sensor.
  • ~OSまたは当の`~device~sensor$が， 前回に報告されたものから（絶対的あるいは相対的に）十分に相違しない読取りを — ~hardwareや~OSの~filterを介して，自動的に — 破棄している。 ◎ the operating system and/or the device sensor automatically discard readings that do not differ enough (in absolute or relative terms) from the previously reported ones via a hardware or operating system filter.
  • %~platform~sensor が`属する~sensor型$の`~threshold検査~algo$に失敗した 【~algoは ~F を返した】 結果、 %~platform~sensor の`最新な読取り~map$は更新されなかった。 ◎ the Sensor instance’s associated sensor type's threshold check algorithm fails and the platform sensor's latest readings are not updated.

5.5. ~sensor読取りを公開するための条件

~UAが所与の`文書$ %文書 に対し `~sensor読取りを公開できる@ （ `can expose sensor readings^en ） のは、 ~AND↓ が満たされるとき, そのときに限られる： ◎ The user agent can expose sensor readings to a Document document if and only if all of the following are true:

• %文書 に`関連な設定群~obj$は、 `~secureな文脈$enVである。 ◎ document’s relevant settings object is a secure context.
• %文書 の`可視性~状態$doc ~EQ `visible^l ◎ document’s visibility state is "visible".
• `~focusと生成元を検査する$( %文書 ) ~EQ ~T ◎ The focus and origin check on document returns true.
• `拡張~仕様$に `特有な条件@ （ `specific conditions^en ） — `拡張~仕様$は、 各自の~sensor型~用に，［ より厳密な要件を成す新たな条件 ］をこの~listに追加してもヨイ。 ◎ Specific conditions: Extension specifications may add new conditions to this list to have stricter requirements for their sensor types.

注記： 上に挙げた条件に加えて，重要な注意は、［ `Sensor$I の各~下位classは、 自身の構築子において `~sensor施策により制御される特能を検査する＠#check-sensor-policy-controlled-features$こと ］および［ `start()$m ~methodは、 `~sensor~accessを要請する$こと ］である。 これらの検査は、 組で， `§ 軽減~策＠#mitigation-strategies$ にて述べられる軽減~策に対応する。 ◎ Note: In addition to the conditions above, it is important to note that Sensor subclasses invoke the check sensor policy-controlled features operation in their constructors, and § 7.1.7 Sensor.start() invokes request sensor access. Together, these checks correspond to the mitigation strategies described in § 4.2 Mitigation Strategies.

注記： ~hardware資源を解放するため、 ~UAは，［ `~sensor読取りを公開できる$ようになるまで，新たに可用な読取りについての通知を休止する ］よう，下層の`~platform~sensor$に要請できる／し得る。 ◎ Note: In order to release hardware resources, the user agent can request underlying platform sensor to suspend notifications about newly available readings until it can expose sensor readings.

6.1. ~sensor型

各 `~sensor型@ （ `sensor type^en ）には、 次に挙げる~dataが結付けられなければナラナイ： ◎ A sensor type must have the following associated data:

• 1 個~以上の`拡張~sensor~interface$たち。 ◎ One or more extension sensor interfaces.

• `~sensor許可~名~群@ （ `sensor permission names^en ） ⇒ `強力な特能$を識別する`名前$たちが成す`空$でない`集合$。 ◎ A non-empty ordered set of associated powerful feature names referred to as sensor permission names.

  注記： 複数の`~sensor型$が、 同じ`名前$を共有し得る。 ◎ Note: Multiple sensor types may share the same name.

• `~sensor特能~名~群@ （ `sensor feature names^en ） ⇒ `施策により制御される特能$を識別する~tokenたちが成す`空$でない`集合$。 ◎ A non-empty ordered set of associated policy-controlled feature tokens referred to as sensor feature names.
• ある`許可~revocation~algo$ ◎ A permission revocation algorithm.
• `最小~標本化~frequency@ ⇒ ある正な数。 これは、 `実装定義$になるか，`拡張~仕様$により定義される。 どちらも設定された場合、 大きい方の値が利用される。 ◎ A minimum sampling frequency, a positive number. It is either implementation-defined or defined by an extension specification. If both are set, the largest value is used.
• `最大~標本化~frequency@ ⇒ ある正な数。 これは、 `実装定義$になるか，`拡張~仕様$により定義される。 どちらも設定された場合、 小さい方の値が利用される。 ◎ A maximum sampling frequency, a positive number. It is either implementation-defined or defined by an extension specification. If both are set, the smallest value is used.

`最小~標本化~frequency$は、 `最大~標本化~frequency$以下になるモノトスル。 ◎ The minimum sampling frequency must not be greater than the maximum sampling frequency.

各`~sensor型$には、 次に挙げる~dataが結付けられてもヨイ — いずれも，無い場合は ε をとるとする： ◎ A sensor type may have the following associated data:

• `既定の~sensor$ ⇒ 【ある`~device~sensor$／`~platform~sensor$。】 ◎ A default sensor.
• `~threshold検査~algo@ （ `threshold check algorithm^en ） ⇒ 所与の［ 別々な 2 個の`~sensor読取り$ ］に対し，真偽値を返す~algo。 これは、 2 つの読取りが十分~相違するか否かを決定する — 当の`~platform~sensor$の`最新な読取り~map$は、 その結果が ~T になる場合に限り，更新される。 ◎ 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.
• `読取り量子化~algo@ （ `reading quantization algorithm^en ） ⇒ 所与の`~sensor読取り$に対し， 正確度に劣る`~sensor読取り$を返す~algo。 ◎ A reading quantization algorithm, which takes a sensor reading and returns a less accurate sensor reading.
• `属する~virtual~sensor型@ ⇒ ある`~virtual~sensor型$ ◎ A virtual sensor type.

6.2. ~sensor

現在の`閲覧~文脈$の`~platform~sensor$には、 次に挙げるものが結付けられるモノトスル： 【各~platform~sensor？／“現在の” とは？】 ◎ The current browsing context's platform sensor must have:

• `作動化された~sensor~obj群@ （ `activated sensor objects^en ） ⇒ 【`Sensor$I ~objたちが成す】`集合$ — 初期~時は`空$とする ◎ An associated set of activated sensor objects, which is initially empty;
• `最新な読取り~map@ （ `latest reading map^en ／ `latest readings^en ／ `latest reading^en ） ⇒ `~map$ — これは、最新な［ 可用な`~sensor読取り$ ］を保持する ◎ An associated latest reading map, which holds the latest available sensor readings.
• `属する~sensor型@ ⇒ ある`~sensor型$ ◎ An associated sensor type.

`最新な読取り~map$は、 `~key$mapとして `timestamp^l を伴う`~entry$を包含する。 その`値$mapは、 高-分解能な時刻印であり， `読取り時刻印$の見積もりを［ ~milli秒数で表出される，`安全でない現在の時刻$1 ］として与える。 ◎ The latest reading map contains an entry whose key is "timestamp" and whose value is a high resolution timestamp that estimates the reading timestamp expressed in milliseconds as an unsafe current time.

`最新な読取り~map$[ `timestamp^l ] は、 初期~時は ~NULL に設定される — `最新な読取り~map$が，以前の`~sensor読取り$を~cacheしていない限り。 ◎ Latest reading["timestamp"] is initially set to null, unless the latest reading map caches a previous reading.

`最新な読取り~map$を成す他の`~entry$は、 各種`~platform~sensor$により測定された物理量の値を保持する。 これらの`~entry$の`~key$mapは、［ 当の`~sensor型$に結付けられた ある`拡張~sensor~interface$ %~interface ］に定義される`属性$ %属性 の`識別子$ %識別子 に合致するモノトスル。 %属性 の取得子の返り値は、 次を呼出すことで容易に得される ⇒ `最新な読取り~mapから値を取得する$( %~interface を実装している~obj, %識別子 ) ◎ The other entries of the latest reading map hold the values of the different quantities measured by the platform sensor. The keys of these entries must match the attribute identifier defined by the sensor type's associated extension sensor interface. The return value of the attribute getter is easily obtained by invoking get value from latest reading with the object implementing the extension sensor interface and the attribute identifier as arguments.

`最新な読取り~map$を成す どの`~entry$も，その`値$mapは、 初期~時は ~NULL に設定されるとする。 ◎ The value of all latest reading entries is initially set to null.

7.1. `Sensor^I ~interface

[`SecureContext$, `Exposed$=(DedicatedWorker, Window)]
interface `Sensor@I : `EventTarget$I {
  readonly attribute `boolean$ `activated$m;
  readonly attribute `boolean$ `hasReading$m;
  readonly attribute `DOMHighResTimeStamp$I? `timestamp$m;
  `undefined$ `start$m();
  `undefined$ `stop$m();
  attribute `EventHandler$I `onreading$m;
  attribute `EventHandler$I `onactivate$m;
  attribute `EventHandler$I `onerror$m;
};

dictionary `SensorOptions@I {
  `double$ `frequency@m;
};

各 `Sensor$I ~objには、 ある`~platform~sensor$が結付けられる。 ◎ A Sensor object has an associated platform sensor.

各~具象- `Sensor$I ~obj %~obj には、 次を満たす ある`~sensor型$ %~sensor型 も結付けられる ⇒ %~obj が実装する ある`~interface$ ~IN %~sensor型 に結付けられた`拡張~sensor~interface$たち ◎ Concrete Sensor objects also have an associated sensor type, which is the sensor type that has their interface among its extension sensor interfaces.

【 遠回しな定義だが、 それ以上のことは，この仕様からは読み取れない。 該当し得るものが複数ある場合、 どれになるかは，個々の`拡張~仕様$により定義されるのかもしれない。 %~obj に結付けられた`~platform~sensor$が`属する~sensor型$を意図しているかもしれないが、 はっきりしない。 】

この仕様に言及される`~task$用の`~task~source$は、 `~sensor~task~source@ （ `sensor task source^en ）とする。 ◎ The task source for the tasks mentioned in this specification is the sensor task source.

navigator.permissions.query({ name: 'accelerometer' }).then(%result => {
    if (%result.state === 'denied') {
        console.log('加速度計~sensorを利用する許可は否認されました。');
        return;
    }

    let %acl = new Accelerometer({frequency: 30});
    let %max_magnitude = 0;
    %acl.addEventListener('activate', () => console.log('測定する用意ができました'));
    %acl.addEventListener('error', %error => console.log(``^~error： ${%error.name}``^));
    %acl.addEventListener('reading', () => {
        let %magnitude = Math.hypot(%acl.x, %acl.y, %acl.z);
        if (%magnitude > %max_magnitude) {
            %max_magnitude = %magnitude;
            console.log(``^最大値： ${%max_magnitude} m/s2``^);
        }
    });
    %acl.start();
});

7.2. `SensorErrorEvent^I ~interface

[`SecureContext$, `Exposed$=(DedicatedWorker, Window)]
interface `SensorErrorEvent@I : `Event$I {
  `SensorErrorEvent@mc(`DOMString$ %type, `SensorErrorEventInit$I %errorEventInitDict);
  readonly attribute `DOMException$I `error$m;
};

dictionary `SensorErrorEventInit@I : `EventInit$I {
  required `DOMException$I `error@mb;
};

`SensorErrorEvent$I の~instanceは、 `~event構築子$に述べられる手続きに従って構築される。 ◎ SensorErrorEvent instances are constructed by following the steps described in Event's constructor.

`error@m 取得子は、 初期化-時の値を返すモノトスル。 それは、 `SensorErrorEventInit$I を介して渡された `DOMException$I ~objを表現する。 ◎ The error attribute must return the value it was initialized to.＼ It represents the DOMException object passed to SensorErrorEventInit.

8.1. ~sensor~objを初期化する

8.2. ~sensor施策により制御される特能を検査する

8.3. ~sensorに接続する

8.4. ~sensor~objを作動化する

8.5. ~sensor~objを非作動化する

8.6. 汎用~sensor許可~revocation~algo

8.7. ~sensor設定群を設定する

8.8. 最新な読取りを更新する

8.9. 最新な読取り更新を報告する

8.10. 新たな読取りを通知する

8.11. 作動化d状態を通知する

8.12. ~errorを通知する

8.13. 最新な読取りから値を取得する

8.14. ~sensor~accessを要請する

8.15. ~focusと生成元を検査する

9.1. ~virtual~sensor

`~virtual~sensor@ （ `virtual sensor^en ）は、 `~device~sensor$の挙動を制御された仕方で模倣する。 それは、 それに接続された`~platform~sensor$たちが在れば，それらへ`~sensor読取り$を報告する。 ◎ A virtual sensor simulates the behavior of a device sensor in controlled ways. It reports sensor readings to zero or more platform sensors connected to it.

`~virtual~sensor$には、 次に挙げる~dataが結付けられる： ◎ A virtual sensor has the following associated data:

• `読取りを供せるか@vS （ `can provide readings flag^en ） ⇒ `真偽値$ ◎ A can provide readings flag (a boolean).

• `要請された標本化~frequency@vS （ `requested sampling frequency^en ） ⇒ `有限な数$【！number】 ◎ A requested sampling frequency (a number).＼

  これは、 定例の`~device~sensor$の実際の標本化~frequencyと同じく不透明な，`実装定義$な値であり、［ `最小~標本化~frequency$vS, `最大~標本化~frequency$vS ］により設定された限界域の中にある。 当の`~virtual~sensor$が どの`~platform~sensor$にも読取りを供していない場合、 0 になる。 ◎ Just like a regular device sensor's actual sampling frequency is opaque, a virtual sensor's requested sampling frequency is an implementation-defined value that lies within the bounds set by the minimum sampling frequency and the maximum sampling frequency. If a virtual sensor is not providing readings to any platform sensor, its requested sampling frequency is 0.

  注記： `要請された標本化~frequency$vSの値は、 とりわけ，それに接続された`~platform~sensor$が［ ある種の標本化~frequencyを要請したかどうか （`~platform~sensor$ごとに相違するかもしれない）や， 当の`~virtual~sensor$を~pollしているかどうか ］に依存する — 後者の事例では、 標本化~frequencyは，まったく要請されないかもしれない。 ◎ Note: Requested sampling frequency's value depends, among other things, on whether connected platform sensors have requested a certain sampling frequency (which might differ per platform sensor), or whether they are polling the virtual sensor, in which case no sampling frequency might have been requested at all.

• `最小~標本化~frequency@vS （ `minimum sampling frequency^en ） ⇒ `有限な数$【！number】 ◎ A minimum sampling frequency (a number).＼

  `~virtual~sensor$は`~device~sensor$でもあるので、 これは，`~device~sensor$の`最小~標本化~frequency$dVに対応する。 ◎ A virtual sensor is a device sensor, so this corresponds to the device sensor's minimum sampling frequency.

• `最大~標本化~frequency@vS （ `maximum sampling frequency^en ） ⇒ `有限な数$【！number】 ◎ A maximum sampling frequency (a number). ＼

  `~virtual~sensor$は`~device~sensor$でもあるので、 これは，`~device~sensor$の`最大~標本化~frequency$dVに対応する。 ◎ A virtual sensor is a device sensor, so this corresponds to the device sensor's maximum sampling frequency.

`~virtual~sensor型@ （ `virtual sensor type^en ）は、 所与の型の~sensorを表現する`文字列$である。 ◎ A virtual sensor type is a string that represents a sensor of a given type.

`型ごとの~virtual~sensor~metadata@ （ `per-type virtual sensor metadata^en ）は、 `~virtual~sensor型$から`~virtual~sensor~metadata$への`有順序~map$であり， 初期~時は空とする。 `拡張~仕様$は、 この`~map$内に［ 自身が定義する`~sensor型$に対応する 1 個以上の~entry ］を定義するベキである。 ◎ The per-type virtual sensor metadata is an ordered map of virtual sensor types to virtual sensor metadata. It is initially empty, and extension specifications should define one or more entries in the map corresponding to the sensor types they define.

`~virtual~sensor~metadata@ （ `virtual sensor metadata^en ）は、 次に挙げる`~item$sctからなる`構造体$である： ◎ A virtual sensor metadata is a struct whose items are:

• `読取り構文解析~algo@vsM （ `reading parsing algorithm^en ） ⇒ ある~algo — 所与の~JSON `Object$jt に対し，［ `~sensor読取り$／ `undefined^jv ］を返す。 ◎ reading parsing algorithm • An algorithm that takes a JSON Object and returns a sensor reading or undefined.

各`~top-level辿可能$は、 `~virtual~sensor対応付け@ （ `virtual sensor mapping^en ） を有する — それは、 `~virtual~sensor型$から`~virtual~sensor$への`有順序~map$である。 ◎ Each top-level traversable has a virtual sensor mapping, which is an ordered map of virtual sensor types to virtual sensor.

注記： `~virtual~sensor対応付け$【！`構造体$】は、 所与の型に属するすべての`~virtual~sensor$に共通な~dataを包含する。 `~virtual~sensor$は、 `~virtual~sensor$を［ 作成する／用立てる ］にあたって変わり得る~dataを包含する。 ◎ Note: The virtual sensor mapping struct contains data that is common to all virtual sensors of a given type. A virtual sensor contains data that can vary on virtual sensor creation and utilization.

注記： `~virtual~sensor対応付け$は、 `~navigable$ではなく`~top-level辿可能$に束ねられる — 所与の`~sensor型$を伴う`~platform~sensor$は、 どの`~navigable$においても，その`~top-level辿可能$navが同じなら同じ`~virtual~sensor$へ接続することが想定されるので。 これは、 現実における挙動 — 同じ~hardware~sensor（または融合~sensor）が異なる`~navigable$たちへ読取りを供する — をより良く真似る。 ◎ Note: Virtual sensor mappings are tied to top-level traversables rather than any navigable because platform sensors with a given sensor type in all navigables with the same top-level traversable are supposed to connect to the same virtual sensor. This better mimics real-world behavior, where the same hardware (or fusion) sensor provides readings to different navigables.

注記： この挙動は、 `web-platform-tests＠https://web-platform-tests.org$ を通して，この仕様の~test法を追加的に援助する — `testdriver.js を介した~WebDriver通信は、すべて test harness を包含している~frameを通う＠https://web-platform-tests.org/writing-tests/testdriver.html#using-test-driver-in-other-browsing-contexts$ ので。 ◎ Note: This behavior additionally aids testing of this specification through web-platform-tests, as all WebDriver communication via testdriver.js goes through the frame containing the test harness.

9.2. 拡張~command

【 この訳では、 この節に利用される `WEBDRIVER$r その他の用語に以下に挙げる表記を用いる： 】

`~error@wdr( %~code )

`~WebDriver~error~code$ %~code を伴う`~WebDriver~error$

`成功@wdr( %~data )

~data~fieldに %~data を伴う`成功$

所与の %値 が `有限な数@ であるとは、 次が満たされることをいう ⇒ ［ %値 は `Number$jt である ］~AND［ %値 ~NIN { `NaN^jv, `+∞^jv, `−∞^jv } ］

{
  "type": "ambient-light",
  "maxSamplingFrequency": 60,
  "minSamplingFrequency": 5
}

10.1. ~securityと~privacy

`拡張~仕様$には、 次が期待される： ◎ Extension specifications are expected to:

• 汎用な`軽減~策＠#mitigation-strategies$に適合すること ◎ conform with the generic mitigation strategies,
• `事例~別に適用される軽減~策＠#mitigation-strategies-case-by-case$ を考慮すること ◎ consider mitigation strategies applied on a case by case basis,
• `~securityと~privacyに関する自己-考査~質問票^cite `SECURITY-PRIVACY-QUESTIONNAIRE$r を評価すること ◎ be evaluated against the Self-Review Questionnaire on Security and Privacy [SECURITY-PRIVACY-QUESTIONNAIRE],
• 特に，`同一-生成元~施策~違反$ — ~sensorが［ 同一-生成元~施策で統治されない，新たな通信~channel ］を公開する場合に発生し得るそれ — に対し評価すること ◎ and in particular, be evaluated against the same-origin policy violations that can arise if sensors expose a new communication channel not governed by the same-origin policy.

10.2. 命名-法

`低level$な~sensor用の `Sensor$I ~interfaceは、 それが結付ける`~platform~sensor$の名前を継ぐベキである。 例えば， `gyroscope^en （ ~gyroscope）を結付ける~interfaceは、 単純に `Gyroscope^I と命名されるベキである。 `高level$な~sensor用の `Sensor$I ~interfaceは、 その`~platform~sensor$が測定する物理量に "Sensor" 接尾辞を結合して命名されるベキである。 例えば，自身からの距離【 `proximity^en／~~近接】を測定している`~platform~sensor$を結付ける~interfaceは、 `ProximitySensor^I と命名されるベキである。 ◎ Sensor interfaces for low-level sensors should be named after their associated platform sensor. So for example, the interface associated with a gyroscope should be simply named Gyroscope. Sensor interfaces for high-level sensors should be named by combining the physical quantity the platform sensor measures with the "Sensor" suffix. For example, a platform sensor measuring the distance at which an object is from it may see its associated interface called ProximitySensor.

`Sensor$I 下位classの属性のうち，`~sensor読取り$の値たちを保持するものは、 これらの値たちを成す全部的な名前を継ぐベキである。 例えば， `Thermometer^I ~interfaceは、 `~sensor読取り$の値を `temperature^m 属性~内に保持するベキである （ `value^m や `temp^m 属性ではなく）。 命名~用の良い出発点は、 `Quantities, Units, Dimensions and Data Types Ontologies^cite `QUDT$r にある。 ◎ Attributes of the Sensor subclass that hold sensor readings values should be named after the full name of these values. For example, the Thermometer interface should hold the sensor reading's value in a temperature attribute (and not a value or temp attribute). A good starting point for naming are the Quantities, Units, Dimensions and Data Types Ontologies [QUDT].

10.3. 単位

`拡張~仕様$は、 `~sensor読取り$の単位を指定しなければナラナイ。 ◎ Extension specifications must specify the unit of sensor readings.

TAG（ `Technical Architecture Group^cite ）による~API設計-原則 `API-DESIGN-PRINCIPLES$r に則り、 すべての時間~測定は，~milli秒数になるベキである。 他のすべての単位は、 `SI Brochure^cite `SI$r に述べられるとおり， 選好~順で次に挙げるいずれかを利用して指定されるベキである ⇒＃ ~SI単位系（ `International System of Units^en ）, ~SIから導出された単位, ~SIとの併用に受容される非~SI単位 ◎終 ただし，例外として、 温度は，~Kelvin【絶対温度】より~Celsiusの方が選好される。 ◎ As per the Technical Architecture Group’s (TAG) API Design Principles [API-DESIGN-PRINCIPLES], all time measurement should be in milliseconds. All other units should be specified using, in order of preference, and with the exception of temperature (for which Celsius should be favored over Kelvin), the International System of Units (SI), SI derived units, and Non-SI units accepted for use with the SI, as described in the SI Brochure [SI].

10.4. 高levelか低levelか，どちらの~sensorを公開するか

これまで，~sensorを~Web~platformに公開している仕様は、 `高level$な~sensor~APIに注力していた。 `GEOLOCATION-API$r `ORIENTATION-EVENT$r ◎ So far, specifications exposing sensors to the Web platform have focused on high-level sensors APIs. [GEOLOCATION-API] [ORIENTATION-EVENT]

これは、 いくつかの理由から適理な~approachであった。 ~~実際, `高level$な~sensorは： ◎ This was a reasonable approach for a number of reasons. Indeed, high-level sensors:

• 開発者の意図を明瞭に伝達する。 ◎ convey developer intent clearly,
• 下層の~hardwareの~sensorがどう機能するかについて親密な知識を要求しない。 ◎ do not require intimate knowledge of how the underlying hardware sensors functions,
• 利用するのが容易である。 ◎ are easy to use,
• ~UAは処理能と~battery寿命を有意に改善できるようになり得る。 ◎ may enable the User Agent to make significant performance and battery life improvements,
• 公開される情報の量や型を減らすことにより，ある種の［ ~privacy／~security ］課題を避ける一助になる。 ◎ help avoid certain privacy and security issues by decreasing the amount and type of information exposed.

しかしながら，仮想現実（ `virtual reality^en ）や拡張現実（ `augmented reality^en ）などの利用事例が数を増やしており、 特に処理能の理由から，~sensorへの`低level$な~accessが要求されている。 ◎ However, an increasing number of use cases such as virtual and augmented reality require low-level access to sensors, most notably for performance reasons.

`低level$な~accessを供することは、 ~Web~app開発者が［ 専門分野に特有な拘束を活用する／ もっと高処理能な~systemを設計する ］ことを可能化する。 ◎ Providing low-level access enables Web application developers to leverage domain-specific constraints and design more performant systems.

`拡張~仕様$は、 `Extensible Web Manifesto^cite `EXTENNNNSIBLE$r の~~原則に従い， 首に`低level$な~sensor~APIを公開することに注力するベキであるが、 `高level$な~APIも — そうすることに明瞭な便益があるときには — 公開するベキである。 ◎ Following the precepts of the Extensible Web Manifesto [EXTENNNNSIBLE], extension specifications should focus primarily on exposing low-level sensor APIs, but should also expose high-level APIs when they are clear benefits in doing so.

10.5. 同じ型の複数の~sensorを可能化するのは、どのようなとき~~相応しくないか？

同じ`~sensor型$の複数の `Sensor$I ~instanceを， 等しい構築~parameterを伴わせて構築することは、 ~hardware資源の不必要な消費に至らせ得るので，勧められない。 ◎ It is not advisable to construct multiple Sensor instances of the same sensor type with equal construction parameters, as it can lead to unnecessary hardware resources consumption.

複数の観測器が［ 新たに可用な`~sensor読取り$ ］の通知に関心がある事例では — 同じ`~sensor型$の複数の~instanceを作成する代わりに — 単独の `Sensor$I ~instanceに`~event~listener$を追加して，単純な `onreading$m ~event~handlerを利用できる。 ◎ In cases when multiple observers are interested in notifications of a newly available sensor reading, an event listener can be added on a single Sensor instance instead of creating multiple instances of the same sensor type and using simple onreading event handler.

逆に，異なる設定群 — `frequency$m ／正確度／`拡張~仕様$に定義される他の設定など — の下での利用を意図するなら、 同じ`~sensor型$の複数の `Sensor$I を作成できる。 ◎ Conversely, multiple Sensors of the same sensor type can be created when they are intended to be used with different settings, such as: frequency, accuracy or other settings defined in extension specifications.

10.6. 定義~要件

`拡張~仕様$は、 `§ ~sensor型＠#model-sensor-type$にて［ 結付けられなければナラナイものとして挙げられた~data ］すべてを定義しなければナラナイ。 ◎ Extension specifications must define all the associated data listed in § 6.1 Sensor Type.

この節は、 それらの~dataの一部について，さらに情報を供する。 ◎ This section provides more information about some of the associated data that extension specifications must specify.

• `拡張~sensor~interface@ （ `extension sensor interface^en ）は、 ~AND↓ を満たす`~interface$でなければナラナイ：

  • `Sensor$I ~IN 当の~interfaceが`継承した~interface群$
  • `構築子~演算$を伴う【！[Constructor]】 — すなわち、 構築-可能である。
  • 前項の構築子は、 次を満たす省略可能な`辞書$を引数にとる ⇒ `SensorOptions$I ~IN 当の辞書が`継承した辞書~群$

  ◎ An extension sensor interface, which is an interface whose inherited interfaces contains Sensor. The extension sensor interface must be constructible. Its [Constructor] must take, as an argument, an optional dictionary whose inherited dictionaries contains SensorOptions.

  `拡張~sensor~interface$は、 `~supportする~sensor~option群@ （ `supported sensor options^en ） — それが~supportする~option【の名前】たちが成す`集合$ — を持つ。 `拡張~仕様$が他を定義しない限り、 `~supportする~sensor~option群$は，単独の~item `frequency^l のみからなるとする。 ◎ The extension sensor interface has a set of supported options referred to as supported sensor options. Unless the extension specification defines otherwise, supported sensor options contain a single item which is "frequency".

  ~UAは、 所与の`拡張~sensor~interface$用の`~supportする~sensor~option群$から， 自身が~supportできない各~sensor~optionに対応する~itemを除去するモノトスル。 ◎ The user agent must remove items from supported sensor options for a given extension sensor interface if it cannot support the corresponding sensor options.

  `拡張~sensor~interface$を成す各`属性$のうち`~sensor読取り$を公開するものは、 `読専$であり，それらの取得子は次の結果を返すモノトスル ⇒ `最新な読取り~mapから値を取得する$( コレ, `属性$の`識別子$ ) ◎ The extension sensor interface attributes which expose sensor readings are read only and their getters must return the result of invoking get value from latest reading with this and attribute identifier as arguments.

• 当の`~sensor型$が`~sensor融合$を表現している場合、 その`~sensor許可~名~群$を成す各`名前$は， 融合~sourceを成す いずれかの`~sensor型$に結付けられたものでなければナラナイ。 ◎ If the sensor type is representing sensor fusion, its sensor permission names must be those associated with the fusion source sensor types.

`拡張~仕様$は、 各`~sensor型$に対し，次に挙げる定義を指定してもヨイ： ◎ An extension specification may specify the following definitions for each sensor type:

• 次を満たす`辞書$ %辞書 ⇒ `SensorOptions$I ~IN %辞書 が`継承した辞書~群$ ◎ A dictionary whose inherited dictionaries contains SensorOptions.
• `既定の~sensor$。 ~deviceが所与の`~sensor型$用に備える`~platform~sensor$は，一般に 1 つだけなので、 その事例では，`既定の~sensor$を定義することは単直である。 複数の`~device~sensor$が共通的な所では、 `拡張~仕様$は，当の`~sensor型$用の`既定の~sensor$を定義しないことにしてもヨイ — とりわけ，そうしてもイミを成さないときには。 ◎ A default sensor. Generally, devices are equipped with a single platform sensor of each type, in which case defining a default sensor is straightforward. For sensor types where multiple sensors are common, extension specifications may choose not to define a default sensor, especially when doing so would not make sense.

10.7. 自動化

~UAの自動化と~appの~test法を可能化するため、 `拡張~仕様$には，次が奨励される： ◎ In order to enable user-agent automation and application testing, extension specifications are encouraged to:

• `型ごとの~virtual~sensor~metadata$に 1 個以上の`~entry$を追加する。 ◎ Add one or more entries to per-type virtual sensor metadata.
• 前項の帰結として， 1 個以上の`~virtual~sensor~metadata$を定義する。 ◎ Consequently, define one or more virtual sensor metadata instances.
• `~sensor型$が`属する~virtual~sensor型$を指定する — それは、 追加した いずれかの`~entry$の`~key$map【！対応している`型ごとの~virtual~sensor~metadata$を成す~entryに利用される~key】に合致するベキである。 ◎ Specify a sensor type's virtual sensor type, which should match the key used in the corresponding per-type virtual sensor metadata entry.

10.8. `許可~API^citeの拡張-法

各`~sensor型$用の `Sensor$I ~interfaceの実装は、 それによる`~sensor読取り$を，結付けられた［ `名前$ ／ `PermissionDescriptor$I【`許可~記述子~型$】 ］により保護するモノトスル。 `低level$な `Sensor$I は、 `名前$として その~interface名を利用してもヨイ （例： `gyroscope^l ／ `accelerometer^l ）。 `~sensor融合$は、 融合の~sourceとして利用される各~sensorに対し，`~accessする許可を要請する$モノトスル。 ◎ An implementation of the Sensor interface for each sensor type must protect its reading by associated name or PermissionDescriptor. A low-level sensor may use its interface name as a name, for instance, "gyroscope" or "accelerometer". Fusion sensors must request permission to access each of the sensors that are used as a source of fusion.

融合された~dataから`低level$な`~sensor読取り$を構築し直すのは困難であっても、 元の情報の一部は，推定され得る。 例えば［ `絶対~方位~sensor$／`地磁気~方位~sensor$ ］が利用されれば，空間における利用者の方位を演繹するのは容易である。 したがって，これらの~sensorは、 磁力計を`利用する許可を要請する$モノトスル — ~deviceの方位についての情報を地球の磁場との関係で供するので。 対照的に，`相対~方位~sensor$は そのような情報を公開しないので、 磁力計を`利用する許可を要請する$必要はない。 ◎ Even though it might be difficult to reconstruct low-level sensor readings from fused data, some of the original information might be inferred. For example, it is easy to deduce user’s orientation in space if absolute or geomagnetic orientation sensors are used, therefore, these sensors must request permission to use magnetometer as it provides information about orientation of device in relation to Earth’s magnetic field. In contrast, relative orientation sensor does not expose such information, thus, it does not need to request permission to use magnetometer.

`PermissionDescriptor$I も利用できる — 正確度または`標本化~frequency$に許容される上限を設定するためとして。 ◎ Permission descriptors can also be used to set maximum allowed limits for accuracy or sampling frequency.＼

dictionary AccelerometerPermissionDescriptor : `PermissionDescriptor$I {
    boolean highAccuracy = false;
    boolean highFrequency = false;
};

10.9. `許可~施策~API^citeの拡張-法

各`~sensor型$用の `Sensor$I ~interfaceの実装には、 1 個（`~sensor融合$は遂行されない場合）または複数個の，`施策により制御される特能$が結付けられる — それらは、 その実装を文書~内で利用できるかどうかを制御する。 ◎ An implementation of the Sensor interface for each sensor type has one (if sensor fusion is not performed) or several policy-controlled features that control whether or not this implementation can be used in a document.

これらの各`施策により制御される特能$の`既定の許容list$は、 `'self'^l とする。 ◎ The features' default allowlist is 'self'.

【 複数の`~sensor型$用の `Sensor$I ~interfaceが同じ特能を共有する場合に、 ~interfaceごとに異なる`既定の許容list$を指定する必要が生じる~~状況は， 今の所は想定されていないようだ。 】

注記： `既定の許容list$ `'self'^l は、 `Sensor$I ~interfaceの実装の用法を，［ 同一-生成元に属する入子な~frame ］には許容するが、［ 第三者-主体~内容による`~sensor読取り$への~access ］は防止する。 ◎ Note: The default allowlist of 'self' allows Sensor interface implementation usage in same-origin nested frames but prevents third-party content from sensor readings access.

`~sensor特能~名~群$は、 それに結付けられた［ 各`施策により制御される特能$を識別する~token ］からなるモノトスル。 ◎ The sensor feature names set must contain policy-controlled feature tokens of every associated feature.

`低level$な`~sensor型$は、 その~interface名を`施策により制御される特能$用の~tokenとして利用してもヨイ — 例： `gyroscope^l ／ `accelerometer^l 。 `拡張~仕様$が他を定義しない限り，`~sensor特能~名~群$は、 同じ`~sensor型$に結付けられた`~sensor許可~名~群$に合致する。 ◎ A low-level sensor may use its interface name as a policy-controlled feature token, for instance, "gyroscope" or "accelerometer". Unless the extension specification defines otherwise, the sensor feature names matches the same type-associated sensor permission names.

<iframe src="https://third-party.com" allow="accelerometer"/></iframe>

Permissions-Policy: accelerometer=()

`~sensor融合$は、 融合の~sourceとして利用される各~sensorの`~sensor特能~名~群$を利用するモノトスル。 ◎ Fusion sensors must use sensor feature names of the sensors that are used as a source of fusion.

<iframe src="https://third-party.com" allow="accelerometer; magnetometer; gyroscope"/>

10.10. ~Web~IDL例

[SecureContext, Exposed=Window]
interface ProximitySensor : Sensor {
    constructor(optional ProximitySensorOptions proximitySensorOptions = {});
    readonly attribute double? distance;
};

dictionary ProximitySensorOptions : SensorOptions {
    double min;
    double max;
    ProximitySensorPosition position;
    ProximitySensorDirection direction;
};

enum ProximitySensorPosition {
    "top-left",
    "top",
    "top-right",
    "middle-left",
    "middle",
    "middle-right",
    "bottom-left",
    "bottom",
    "bottom-right"
};

enum ProximitySensorDirection {
    "front",
    "rear",
    "left",
    "right",
    "top",
    "bottom"
};