declarations in section 6.5.1 (20170316 version) are wrong

[paulhiggs]

In section 6.5.1 (https://www.w3.org/TR/tvcontrol-api/#dictionary-tvsourcesupportedconstraints-members) the members are defined as boolean with default value of "true"

Same for section 6.7.1 (https://www.w3.org/TR/tvcontrol-api/#dictionary-tvsourceconstraints-members)

[tidoust]

Section 6.7.1 is indeed incorrect. The IDL definition in 6.7 is correct but the prose is wrong.

I believe section 6.5.1 is correct though: the TVSourceSupportedConstraints dictionary lists the constraints recognized by a user agent. All members are boolean, as expected. This is similar to the MediaTrackSupportedConstraints interface from Media Capture and Streams.

I'll create another issue for TVSourceSupportedConstraints as we seem to have lost ourselves in the constraint pattern in the current spec: TVSourceSupportedConstraints is not referenced anywhere.

[paulhiggs]

Perhaps we need some other terms then..
6.5.1 says

6.5.1 Dictionary TVSourceSupportedConstraints Members
deliverySystem of type boolean defaulting to true
See deliverySystem for details.
height of type boolean defaulting to true
See height for details.
channel of type boolean defaulting to true
See channel for details.
tuningStep of type boolean defaulting to true
See tuningStep for details.

Looking at tuningStep in 6.6 it is defined as a long and clicking on it takes me to a definition in 6.9 where it is defined as a ConstrainLong. No boolean in sight there!
Looks to be the same when clicking on height and channel in 6.5.1.

[tidoust]

This follows the same pattern as in the Media Capture and Streams spec, but that's indeed unclear. Goal is to link to the description of the meaning of each constraint, not to their type.

We could perhaps replace "See deliverySystem for details" (and other similar sentences) by "Whether the deliverySystem constraint is supported".

[stevem-tw]

I've hopefully fixed both issues (the suggested rewording and correcting the types in 6.7) in the latest editor's draft. Section 6.5.1 is correct, although it's easy to understand the confusion. having fixes some of the other related issues, this area should now be a little clearer.

[paulhiggs]

Seems to be dead...