https://logs.xmpp.org/council/2020-06-03?p=h#2020-06-03-224e106ade90e632
1) Roll Call Present: Jonas, Dave, Zash, Daniel Semi-present: Georg 2) Agenda Bashing No additions. 3) Editor's Update * Calls in Progress - CFE for XEP-0050 (ends at 2020-06-09) 4) Items for a Vote None, as far as Jonas can tell. 5) Outstanding Votes Georg has some, but is still catching up. 6) Date of Next 2020-06-10 1500 UTC 7) AOB Kev was expecting some response to his comments about XEP-0393 [1] - Jonas did read them, but didn't have anything to add, though is also somewhat fatigued by the discussion; Dave did mention exploring Kev's proposal in one of his responses. Dave liked the suggestion of a flag to indicate "I know what I'm doing so you can strip the markup," but thinks that really needs a formal grammar. Kev summarises: if you include an opt-in then it signals to a screen-reader (for example) that it can strip the markup to make it accessible, without changing other semantics; which doesn't solve all cases, but greatly helps accessibility in some - Sam thinks this appears to be a fairly convincing argument, but will have to consider how it interacts with other things. Dave found Larma's treatise [2] to be very useful. As the XEP-0393 discussion on-list has been quite lively, Jonas would prefer to move this out of the meeting. Jonas considers it convenient that Kev is around, as he was involved in the previous iteration of the XEP-0050 'execute' issue, and seems to recall he had a concrete suggestion on what to do - Kev thinks he did too, though what that actually was is another matter. Conveniently, Tedd had already quoted the appropriate portion of the minutes [3]. Looking at PR #598, the Editor closed it due to being from the previous Council period and nobody cared enough to process it; Jonas suggests re-opening and voting on it next week. Additionally, Jonas would like to suggest that the author, Kev, add some wording around deprecation of the execute action to avoid any pitfalls. Zash requests a simple explanation of the issue - Jonas obliges: action='execute' is always allowed; if the @execute is not set, action='execute' is equivalent to action='next'; if the form specifies a list of allowed actions which does not include next -> undefined behaviour. Kev considers that a remarkably coherent explanation. Jonas thinks Kev's PR addresses this in a good way, but would just like another paragraph which hints at not using 'execute' if it can be avoided. Kev will need to re-read to be sure, and to see how it differs from Dave's suggestion of deprecating the execute action - Jonas thinks it's orthogonal as the PR explicitly states that a form is invalid if it has an 'actions' element, but 'next' is not an available action and there is no 'execute' attribute. Kev remembers this as being an "everything is broken" situation. Kev doesn't expect to have time to handle this at the moment - Jonas will take advantage and hijack the PR, then re-propose it to Council next week. Flow would like to point out PR #591 as an alternative suggestion - Jonas notes that Council vetoed it and discussed rewording to make the intention clear. 8) Close Thanks everyone. [1] https://mail.jabber.org/pipermail/standards/2020-June/037512.html (and https://mail.jabber.org/pipermail/standards/2020-June/037514.html) [2] https://mail.jabber.org/pipermail/standards/2020-June/037506.html [3] https://mail.jabber.org/pipermail/standards/2020-May/037489.html
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
