Re: [mediacapture-main] Fitness distance steps 4 and 5 are inconsistent with the rest of the spec (#933)

> > Steps 4 an 5 refer to settings dictionaries as if they were IDL dictionaries, having members. But settings dictionaries are not IDL dictionaries and their internal structure understood to be an implementation detail elsewhere in the spec.
> > The spec explicitly says `We use the term settings dictionary for the set of values that might be applied as settings to the object.`, which does not necessarily translate to they working like IDL dictionaries with explicit members that might or might not be present.
> 
> Settings dictionaries are not IDL dictionaries but the name _settings dictionary_ still implies that they are dictionaries. A dictionary is commonly defined to be data structure which has keys and values associated to those keys and its main immutable operations are to test the existence of a key and to retrieve the value associated to an existing key.
> 
If they're not necessarily IDL dictionaries we shouldn't link to the definition of IDL dictionaries when talking about existence of fields. The implementation of SelectSettings does not require that we have a list of IDL Settings dictionaries that are checked individually (and, for example, the Chromium implementation doesn't follow that approach). It can be the case that support for a particular property is determined by calling some system API and taking a code path that covers multiple dictionaries simultaneously.

> > Another problem is that step 4 says `If constraintValue is a boolean, but the constrainable property is not`, which sounds impossible in IDL.
> 
> It depends on the definition of the _constrainable property_ which I think is not properly defined in the spec.
> 

I would say that it is. The term constrainable property refers to a name (and type) associated with a constrainable object, which has Capabilities,  Constraints and Settings. There is a an IDL template for these concepts. See https://w3c.github.io/mediacapture-main/#interface-definition-0

> > I understand that this is intended to support pan/tilt/zoom constraints which accept boolean and numeric values. These constraints are of type (boolean or ConstraintDouble), so the constraint value is compatible with the property.
> 
> [The Terminology section](https://w3c.github.io/mediacapture-main/#terminology) defines [Constraints](https://w3c.github.io/mediacapture-main/#dfn-constraint) and states that "[f]or each constrainable property, a constraint exists whose name corresponds with the relevant source setting name and capability name". So clearly a _constrainable property_ and a _constraint_ are two different things. Therefore, if a constraint is of type `(boolean or ConstraintDouble)`, it does not mean that the corresponding constrainable property is of that type.
> 
> On the other hand, the [Constrainable Properties](https://w3c.github.io/mediacapture-main/#constrainable-properties) subsection under the [MediaStream API](https://w3c.github.io/mediacapture-main/#stream-api) section seems to kind of imply that _constrainable property_ and a _constraint_ mean the same.
> 

Since constrainable objects are a pattern they don't have a single explicit type, but it is easy to see that they have an implicit type that is expressed in different ways for settings, constraints and capabilities.
For example, in the case of frameRate, its settings are of type double, its capabilties is of type [DoubleRange](https://w3c.github.io/mediacapture-main/#dom-doublerange), and constraints are of type [ConstraintDouble](https://w3c.github.io/mediacapture-main/#dom-constraindouble). It is impossible to have a string to express a constraint, setting or capability for frameRate.

Since properties are a pattern and not a specific IDL definition (beyond the name of the property), sometimes the spec uses the setting type when describing the property and sometimes it uses the constraint type. I agree that the spec should be more consistent here, but that doesn't change the fact that the types for settings, capabilities and constraints have to be compatible and you can't have an unrelated type as one of its values.

> Could the step 4 be clarified to be `If constraintValue is a boolean, but the setting of the property is not`? The term _the setting of this property_ is used elsewhere in the spec.
> 

This doesn't make sense because if you define a type in IDL (and you have to do it for constraints) the only possible values have to correspond to that type. Having a step to cover the case where the value does not correspond to its type is unnecessary/incorrect since that value wouldn't exist.

> > One way to make this clearer is to treat this particular constraint type separately, just like purely numeric constraints are treated separately from purely boolean/enum/string constraints.
> 
> Yes, that is one option for the step 4.
> 

Let's go for it then.


> But please note that the step 5 is in no way limited to constraints of type `(boolean or ConstraintDouble)`. It affects also for instance the 'focusMode' constraint of type `ConstrainDOMString`, the 'focusDistance' constraint of type `ConstrainDouble` and the 'backgroundBlur' constraint of type `ConstraintBoolean`. The step 5 defines that the fitness distance for an ideal constraint is 1.0 if the underlying device does not support the property or if the settings dictionary does not [expose](https://w3c.github.io/mediacapture-main/#dfn-must-not-be-exposed) the property. Of course that could be integrated to the steps 7 and 8 were the step 5 to be removed.

There are already definitions of fitness distance for strings, doubles and booleans, so I see no need to define anything different for those properties. If these properties should be treated differently to other booleans, strings and doubles they should have a different type and we can make fitness distance definitions for those types.

This concept of having the settings dictionary member exist or not just introduces unnecessary complexity based on things that are either impossible or impractical and we should remove it. Why do we need anything beyond the concept of the setting dictionary not supporting the constraint value ?

IMO, we should just return to the [old fitness distance definition](https://www.w3.org/TR/2020/CRD-mediacapture-streams-20200924/#dfn-fitness-distance) and just add an extra step on how to calculate its value for the (boolean or ConstraintDouble) type.

Why do you think we should do anything different from that?


-- 
GitHub Notification of comment by guidou
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/933#issuecomment-1451602833 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 2 March 2023 10:00:30 UTC