Indicating relative weight of the Receiver's constraint sets

[garethsb]

Regarding relative quality/preference, the following Constraint Set metadata item would give us something very consistent with the 'media type quality factor' (qvalue) used in HTTP content negotiation, defined by RFC 7231 Section 5.3.

"properties": {
  ...
  "urn:x-nmos:cap:meta:qvalue": {
    "description": "The qvalue or quality factor expresses the relative 'weight' that the Receiver assigns to its preference for the streams satisfied by the associated Constraint Set. The weight is normalized to a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; a value of 0 means 'not acceptable'.",
    "type": "number",
    "default": 1,
    "maximum": 1,
    "minimum": 0,
    "multipleOf": 0.001
  }
}

Would this fit the use cases that have been identified, e.g. by the EDID-based connection management activity?

(The distinction between the meaning of 0 and 0.001 comes from RFC 7231. We wouldn't have to follow this if the group feel it causes more trouble than it's worth.)

[garethsb]

OK, an alternative proposal to flexibly indicate 'relative weight' of the Receiver's preferences using an integer value, in reasonably terse syntax..

Each Constraint Set may have a urn:x-nmos:cap:meta:preference attribute which is an integer, in the range -100 to +100.

When a Receiver does not want to indicate preference, it may omit the preference attribute.

When a Controller does not support receiver preference, it just ignores any preference attribute.

When a Receiver wants to indicate preference, it may add the attribute to all Constraint Sets, or only to some in which case the other sets have an effective value of 0.

When a Receiver supports a few 'native' options, and many that require some transformation, it can just explicitly associate a positive value with the native options (since the many will have a lower effective value of 0).

When a Receiver supports many options well, but a few low-quality options are provided to be used 'at a pinch', it can just explicitly associate a negative value with those options (since the many will have a higher effective value of 0).

"properties": {
  ...
  "urn:x-nmos:cap:meta:preference": {
    "description": "This value expresses the relative 'weight' that the Receiver assigns to its preference for the streams satisfied by the associated Constraint Set. The weight is an integer in the range -100 through 100, where -100 is least preferred and 100 is most preferred. When the attribute is omitted, the effective value for the associated Constraint Set is 0.",
    "type": "integer",
    "default": 0,
    "maximum": 100,
    "minimum": -100
  }
}