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

> > > 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.
> 
> `MediaTrackConstraintSet` WebIDL defines pan constraint to be of type `(boolean or ConstrainDouble)` so _constraintValue_ for pan can be a boolean where as `MediaTrackSettings` WebIDL defines pan setting to be of type `double` so it definitely is not a boolean. So the value does correspond its type but not its setting's type. IMHO that makes sense.
> 

But the concept we are interested in is whether a dictionary setting satisfies a constraint or not, see [Step 2](https://w3c.github.io/mediacapture-main/#dfn-fitness-distance). Thus, having a numeric setting and a boolean value for the constraint doesn't mean that the setting cannot be checked to satisfy the constraint. IIUC, if the setting supports any numeric value it means it satisfies a true value for the constraint.
I see no need to add additional language there other than specifying how to compute the numeric values for the fitness in the step specific to (boolean or ConstraintDouble). 

> > There are already definitions of fitness distance for strings, doubles and booleans, so I see no need to define anything different for those properties.
> 
> For all positive numeric constraints, the fitness distance is the result of the formula `(actual == ideal) ? 0 : |actual - ideal| / max(|actual|, |ideal|)`. What if a site calls `navigator.mediaDevices.getUserMedia({iso: 400})` and there is a source which does not support ISO? An implementation should compute (or simulate to compute) the fitness distance between the constraints and all possible settings dictionaries. It is clear that _ideal_ is 400 in this case but what is _actual_? There is no actual ISO. The source does not support ISO. So that definition would need an addition stating that the fitness distance in this case is 1 because there are no actual value. But that is exactly what the step 5 tries to do.
> 

I see your point. The phrasing looked very confusing to me. I think we should phrase it differently for extra clarity. Something like  `If an ideal value is specified and the settings dictionary cannot support any value for the property, the fitness distance  is 1` .


> Of course, it is possible to remove the step 5 and integrate it in and repeat at steps 7 and 8.
>

Now that I see the intent, I would keep it, but with the rephrasing above.

 
> > 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.
> 
> Wouldn't that basically be a combination of the current steps 4 and 7?

My summary is that we should:
* Eliminate Step 4
* Keep the current Step 5, but rephrase it for extra clarity.
* Add a step to explain how to compute the fitness distance for (boolean or ConstraintDouble) constraints.

Do you agree?

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


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

Received on Tuesday, 7 March 2023 09:31:40 UTC