Conversation
| <!-- Recording optout status 'true' means: The speaker does not want a recording of any kind. We will remove all personnel, and maybe even switch off all cameras --> | ||
| <xs:enumeration value="true"/> | ||
| <!-- Recording optout status 'maybe': We are allowed to create a recording / enable the live stream; but the speaker can decide afterwards if we can publish it --> | ||
| <xs:enumeration value="maybe"/> |
There was a problem hiding this comment.
How about undecided instead of maybe?
There was a problem hiding this comment.
| <xs:enumeration value="maybe"/> | |
| <xs:enumeration value="undecided"/> |
|
|
||
| <xs:simpleType name="optoutEnum"> | ||
| <xs:restriction base="xs:string"> | ||
| <!-- Recording optout status 'false' is the normal case: We enable the live stream and create a recording, which we publish without and feedback from the speaker --> |
There was a problem hiding this comment.
Readability/understanding: which we publish without and feedback from the speaker could be which we publish without or with feedback from the speaker
| "do_not_stream": { | ||
| "type": ["string", "null"] | ||
| "type": ["string", "boolean", "null"], | ||
| "description": "If this value is set to boolean `false`, the speaker is okay with a live stream of the event; and is aware that somebody in the internet might create third party recording" |
There was a problem hiding this comment.
Should with a live stream be with a recording but not with a live stream?
There was a problem hiding this comment.
for the schedule.json, I would propose following assignment for a talk without recording + live-stream:
"do_not_record": true,
"do_not_stream": true,The following assignment is a talk without a recording, but with a livestream:
"do_not_record": false,
"do_not_stream": true,| </xs:simpleContent> | ||
| </xs:complexType> | ||
|
|
||
| <xs:simpleType name="optoutEnum"> |
There was a problem hiding this comment.
My understanding of recording and streaming is that both are independent from each other. As a user I would expect to see these flags in the schedule being presented as separate icon or similar. Is that possible with the enum or should it be split up?
There was a problem hiding this comment.
For the XML schedule variant: I think we should try to combine both...
There was a problem hiding this comment.
What is the reasoning for combining both?
|
@johnjohndoe It's complicated... For a proper solution we should first think about the UI in which the speakers performs this choices... See https://git.cccv.de/hub/hub/-/issues/373#note_18383 for more information. This PR was thougth as a first step for 37C3 Saal E (SoS Lightning)... but we probably won't find the time to do it properly this round... |
|
I added a table with a first mapping between the JSON and XML variants to the pull request description |
|
I am still struggling with the negation (
As these fields would be new to the json/xml API clients could migrate at their own pace without being broken. |
|
The problem is that we already have But yeah, we should stop with this asymmetry between the json and xml variants. |
|
I imagine that adding semantic versioning to the schema, json, xml would allow to introduce new fields and also to deprecate and remove old fields. |
2 participants
relates to #117
"do_not_record": falseor"do_not_record": false, "do_not_stream": false,<recording>…<optout>false</optout></recording>"do_not_record": true, "do_not_stream": true,<recording>…<optout>true</optout></recording>"do_not_record": null, "do_not_stream": false,<recording>…<optout>maybe</optout></recording>"do_not_record": null, "do_not_stream": null,<recording>…<optout>unknown</optout></recording>