-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ARG mux proposal #30
base: v1.0.x
Are you sure you want to change the base?
ARG mux proposal #30
Conversation
* Create substream_constraints.json * Update constraint_set.json - to include the new substreams property * Update Examples.md - to add MUX example using substreams * Update APIs/schemas/substream_constraints.json to an "open enum" Co-authored-by: Gareth Sylvester-Bradley <[email protected]> * Update Examples.md in line with the latest schema update for "format" * Update Receiver Capabilities.md To add substreams section * Change "MUX" to "mux" --------- Co-authored-by: Gareth Sylvester-Bradley <[email protected]>
to include better descriptions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Annotating with discussion in recent ARG calls
@@ -20,6 +20,13 @@ | |||
"description": "This value indicates whether a Constraint Set is available to use immediately (true) or whether this is an offline capability which can be activated via some unspecified configuration mechanism (false). When the attribute is omitted its value is assumed to be true.", | |||
"type": "boolean", | |||
"default": true | |||
}, | |||
"urn:x-nmos:substreams": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've discussed that in order to maintain BCP-004-01 v1.0 compatibility this cannot be urn:x-nmos:cap:substreams
because of the pattern property below. But not clear whether urn:x-nmos:substreams
name is precise enough.
{ | ||
"$schema": "http://json-schema.org/draft-04/schema#", | ||
"description": "Describes substream constraints", | ||
"title": "Constraint Set", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"title": "Constraint Set", | |
"title": "Substream Constraints", |
"type": "object", | ||
"minProperties": 1, | ||
"properties": { | ||
"description": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each constraint set uses URN attribute names, since the parameter constraints in each set are intended to be extensible, and the metadata attributes therefore also have URNs, like urn:x-nmos:cap:meta:label
.
Here it probably does make sense to use "simple" attribute names, like format
and count
(or minimum
tbc). Should this one be description
or label
?
"count": { | ||
"$ref": "param_constraint_number.json" | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've discussed that most/all mux Receivers are capable of discarding substreams they are not interested in. Therefore we started discussing whether a minimum
attribute could be simpler and sufficient?
E.g. something like
"count": { | |
"$ref": "param_constraint_number.json" | |
}, | |
"minimum": { | |
"type": "integer", | |
"default": 1, | |
"minimum": 0 | |
}, |
No description provided.