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

I think the issue can be resolved if we are more explicit  and consistent at defining a few things. 

Some examples of ambiguity:

* In [Step 3 of applyConstraints](https://w3c.github.io/mediacapture-main/#dom-mediastreamtrack-applyconstraints) it says that a settings dictionary "_refers to a possible instance of the [MediaTrackSettings](https://w3c.github.io/mediacapture-main/#dom-mediatracksettings) dictionary_", which is IDL. But [settings dictionary](https://w3c.github.io/mediacapture-main/#dfn-settings-dictionary) are also defined as "_the set of values that might be applied as settings to the object_", which is a more flexible definition where the only important concept is supporting a constraint or not, regardless of the implementation of the dictionary. If we do decide that a settings dictionary is an instance of the [MediaTrackSettings](https://w3c.github.io/mediacapture-main/#dom-mediatracksettings) WebIDL type, that's fine, but then let's be explicit about it  everywhere, and about what not having a field means.

* The expression "type of a constrainable property".  A constrainable property is a pattern that has settings, constraints and capabilities. The types for those three things can be different, but whenever we have a constraint value coming from WebIDL, that value is valid (as a constraint) even if it is not the same type of the setting. Saying that it is not of the same type of the property sounds misleading as it suggests that it is possible to specify a constraint value that is invalid or incompatible for the property. Nowhere in the spec it is established that the type of a property is the type of its setting. Moreover, it is not immediately obvious to me that the type of a property whose constraints are (boolean or ConstraintDouble) is the same as the type of a property whose constraints are ConstraintDouble, even if settings are of type double for both of them. Maybe we can define somewhere that the expression "type of a constraintable property"  is a shorthand for the type of its setting.

* I think the case of the [fitness distance](https://w3c.github.io/mediacapture-main/#dfn-fitness-distance) for (boolean or ConstraintDouble) constraints would be more readable with an explicit step for that constraint type, similar to how steps 7 and 8 are handled for other constraint types rather than having an early step to handle the case where the constraint value is boolean but the property is not, especially if we are not explicit about what the type of a property is.

All this said, I think the interaction between constraint values and dictionary settings only require the concept of a dictionary setting satisfying a constraint value or not, and letting implementations decide how dictionary settings are implemented and how they satisfy a constraint value. But I agree that defining dictionary settings as instances of MediaTrackSettings is probably the way that requires fewer changes.


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


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

Received on Thursday, 30 March 2023 12:02:46 UTC