Re: [Standards] undefined state in XEP-0050
On 5 Mar 2018, at 14:21, Kevin Smith wrote: > > > On 28 Feb 2018, at 19:13, Florian Schmaus wrote: >> But this is unlikely to change ever. So here is how I understand it: - 'execute' always gets you into the next stage, and iff 'next' is an allowed action, then 'execute' is equivalent to 'next', or otherwise it is equivalent to 'complete’. >>> >>> I think that if we follow what 50 says, we actually reach the conclusion >>> that if execute isn’t set on actions, it’s equivalent to next, which may be >>> disabled. Which basically means that an actions list not including next and >>> not including an execute value is saying “The default is next, and it’s >>> disabled”, which is more or less a broken xep 50 command so the responder >>> shouldn’t send it. Changing to have the default switch to complete if >>> there’s no next is probably not harmful, although is a change in behaviour >>> from what we have. >> >> The question is: (1) Do we want to allow 'execute' to be at a given >> point equivalent to a disabled action, which, when used, would result in >> a bad-command error response, *or* do we want to avoid that by either >> >> (2) Specifying that execute → next, if 'next' is not disabled >> → complete, otherwise >> (3) Specifying that the responder must always provide an 'execute' >> attribute if 'next' is a disabled action. >> >> I'd love to go with either (2) or (3), but if you assume that (1) is >> currently xep50 compliant, then this means a backwards incompatible >> change, which would require a namespace bump. >> >> A compromise would probably be only recommending (3) in the XEP. > > I think (3) is what we already have, we just don’t call attention to is. That > is - with the current text, if you (as a responder) send no execute > attribute, and next is disabled, you’ve sent a broken form. So I think it’s > sufficient to say “And obviously if you send …, you’ve sent a broken form”. > This is no change in behaviour, and so no need for bumps, etc. > > I’ve just opened this in my editor to have a bash at it, but then realised > I’m about to (virtually) walk into a meeting. I’ll try to have a bash later > this afternoon. In the end I decided that while the words were convoluted, that’s because the underlying logic is convoluted. I’ve got some suggested words up at https://github.com/xsf/xeps/pull/598 that might or might not make things better. They are intended to be consistent with what’s already there, but just draw to attention the discussed invalid state. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] undefined state in XEP-0050
On 28 Feb 2018, at 19:13, Florian Schmaus wrote: > >>> But this is unlikely to change ever. So here is how I understand it: >>> >>> - 'execute' always gets you into the next stage, and iff 'next' is an >>> allowed action, then 'execute' is equivalent to 'next', or otherwise it >>> is equivalent to 'complete’. >> >> I think that if we follow what 50 says, we actually reach the conclusion >> that if execute isn’t set on actions, it’s equivalent to next, which may be >> disabled. Which basically means that an actions list not including next and >> not including an execute value is saying “The default is next, and it’s >> disabled”, which is more or less a broken xep 50 command so the responder >> shouldn’t send it. Changing to have the default switch to complete if >> there’s no next is probably not harmful, although is a change in behaviour >> from what we have. > > The question is: (1) Do we want to allow 'execute' to be at a given > point equivalent to a disabled action, which, when used, would result in > a bad-command error response, *or* do we want to avoid that by either > > (2) Specifying that execute → next, if 'next' is not disabled >→ complete, otherwise > (3) Specifying that the responder must always provide an 'execute' > attribute if 'next' is a disabled action. > > I'd love to go with either (2) or (3), but if you assume that (1) is > currently xep50 compliant, then this means a backwards incompatible > change, which would require a namespace bump. > > A compromise would probably be only recommending (3) in the XEP. I think (3) is what we already have, we just don’t call attention to is. That is - with the current text, if you (as a responder) send no execute attribute, and next is disabled, you’ve sent a broken form. So I think it’s sufficient to say “And obviously if you send …, you’ve sent a broken form”. This is no change in behaviour, and so no need for bumps, etc. I’ve just opened this in my editor to have a bash at it, but then realised I’m about to (virtually) walk into a meeting. I’ll try to have a bash later this afternoon. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] undefined state in XEP-0050
On 22.02.2018 10:28, Kevin Smith wrote: >> On 21 Feb 2018, at 18:50, Florian Schmaus wrote: >> On 06.08.2015 17:42, Goffi wrote: >>> My guess is that "execute" should be equivalent to "complete" when >>> "next" is not possible (but what if "complete" is disabled too ?). >> >> I think it is a little design weakness of XEP-0050: Ad-Hoc Commands that >> we have 'next' and 'execute'. It appears the whole protocol would be >> much simpler and less confusing if we just had 'execute’. > > Execute is convenient - it’s not an action of its own per se, it’s just > saying which of the provided actions is used by default (e.g. will be run > when the user hits Enter), but allowing it to be sent as an action= value > could have been better thought-out, I suspect (even then, it’s useful for the > first stage of the form). So I suspect the underlying issue described here is > UIs wrongly showing independent buttons for Execute and whatever Execute > should mean. No, it is about simplicity and that I don't see why there shouldn't be a combined *action* of 'next' and 'execute'. It is not about and unrelated to the existence of the 'execute' attribute. >> But this is unlikely to change ever. So here is how I understand it: >> >> - 'execute' always gets you into the next stage, and iff 'next' is an >> allowed action, then 'execute' is equivalent to 'next', or otherwise it >> is equivalent to 'complete’. > > I think that if we follow what 50 says, we actually reach the conclusion that > if execute isn’t set on actions, it’s equivalent to next, which may be > disabled. Which basically means that an actions list not including next and > not including an execute value is saying “The default is next, and it’s > disabled”, which is more or less a broken xep 50 command so the responder > shouldn’t send it. Changing to have the default switch to complete if there’s > no next is probably not harmful, although is a change in behaviour from what > we have. The question is: (1) Do we want to allow 'execute' to be at a given point equivalent to a disabled action, which, when used, would result in a bad-command error response, *or* do we want to avoid that by either (2) Specifying that execute → next, if 'next' is not disabled → complete, otherwise (3) Specifying that the responder must always provide an 'execute' attribute if 'next' is a disabled action. I'd love to go with either (2) or (3), but if you assume that (1) is currently xep50 compliant, then this means a backwards incompatible change, which would require a namespace bump. A compromise would probably be only recommending (3) in the XEP. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] undefined state in XEP-0050
On 2/22/18 3:46 AM, Kevin Smith wrote: > On 22 Feb 2018, at 10:24, Jonas Wielicki wrote: >> >> On Donnerstag, 22. Februar 2018 10:29:18 CET Kevin Smith wrote: >>> FWIW, I think this isn’t what the standard already says, although may be >>> sensible. >> >> Hmm… I think you are right there. "execute" is equivalent to whatever the >> Responder says in the "execute" attribute on . Which unfortunately >> does *not* have a default value. The interpretation of being equivalent to >> "next" is only done in a "typical interpretation" of a requester: >> >>> The action "execute" is always allowed, and is equivalent to the action >>> "next". >> >> (this is the passage which is to be changed) and later on: >> >>> If the possesses the "execute" attribute, that value is the >>> default button or option. If the does not possess the "execute" >>> attribute, there is no default button or option. >> >> Also, there is (for empty/no ): >> >>> The action "execute" is equivalent to the action "complete”. > > Yes, it’s slightly spaghetti-ish isn’t it? Indeed. >> So given all that, I wonder whether the proposed wording should be adapted >> to >> reflect that the value of the "execute" attribute should always take >> precedence over the interpretation of what "execute" means? > > I think that’s what the XEP already says, in not-the-clearest terms. All the > defaults are just fallbacks for when execute= isn’t specified. Right. Somewhere in a stack of papers I likely still have a round of edits I was going to propose to Matt Miller back in 2011(?) but never entered into a computer... > I suspect that a reword of the whole section would be sensible. I don’t know > if Flow wants to give this a go, as he started this, or I can do so. Have at it! Peter signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] undefined state in XEP-0050
On 22 Feb 2018, at 10:24, Jonas Wielicki wrote: > > On Donnerstag, 22. Februar 2018 10:29:18 CET Kevin Smith wrote: >> FWIW, I think this isn’t what the standard already says, although may be >> sensible. > > Hmm… I think you are right there. "execute" is equivalent to whatever the > Responder says in the "execute" attribute on . Which unfortunately > does *not* have a default value. The interpretation of being equivalent to > "next" is only done in a "typical interpretation" of a requester: > >> The action "execute" is always allowed, and is equivalent to the action >> "next". > > (this is the passage which is to be changed) and later on: > >> If the possesses the "execute" attribute, that value is the >> default button or option. If the does not possess the "execute" >> attribute, there is no default button or option. > > Also, there is (for empty/no ): > >> The action "execute" is equivalent to the action "complete”. Yes, it’s slightly spaghetti-ish isn’t it? > > So given all that, I wonder whether the proposed wording should be adapted to > reflect that the value of the "execute" attribute should always take > precedence over the interpretation of what "execute" means? I think that’s what the XEP already says, in not-the-clearest terms. All the defaults are just fallbacks for when execute= isn’t specified. I suspect that a reword of the whole section would be sensible. I don’t know if Flow wants to give this a go, as he started this, or I can do so. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] undefined state in XEP-0050
On Donnerstag, 22. Februar 2018 10:29:18 CET Kevin Smith wrote: > FWIW, I think this isn’t what the standard already says, although may be > sensible. Hmm… I think you are right there. "execute" is equivalent to whatever the Responder says in the "execute" attribute on . Which unfortunately does *not* have a default value. The interpretation of being equivalent to "next" is only done in a "typical interpretation" of a requester: > The action "execute" is always allowed, and is equivalent to the action > "next". (this is the passage which is to be changed) and later on: > If the possesses the "execute" attribute, that value is the > default button or option. If the does not possess the "execute" > attribute, there is no default button or option. Also, there is (for empty/no ): > The action "execute" is equivalent to the action "complete". So given all that, I wonder whether the proposed wording should be adapted to reflect that the value of the "execute" attribute should always take precedence over the interpretation of what "execute" means? kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] undefined state in XEP-0050
On 22 Feb 2018, at 08:24, Jonas Wielicki wrote: > > On Mittwoch, 21. Februar 2018 19:50:17 CET Florian Schmaus wrote: >> On 06.08.2015 17:42, Goffi wrote: >>> G'day, >>> >>> there is a little issue with XEP-0050: in section 3.4 bullet 3, it's is >>> said that when the element is present: >>> >>>- The action "execute" is always allowed, and is equivalent to the >>> action "next". >>>- The "next" action is typically the "next" button or option in a >>> wizard. If is not contained by the , it is disabled. >>> >>> So if "next" action is disabled, execute is allowed but equivalent to a >>> disabled action. >>> >>> I have had an issue which seems related to this confusion with SleekXMPP >>> and Gajim: if the next action is disabled in sleekXMPP, Gajim still show >>> the "execute" button, but a click on it result in an error, while the >>> "finish" button act as expected. >>> >>> My guess is that "execute" should be equivalent to "complete" when >>> "next" is not possible (but what if "complete" is disabled too ?). >> >> I think it is a little design weakness of XEP-0050: Ad-Hoc Commands that >> we have 'next' and 'execute'. It appears the whole protocol would be >> much simpler and less confusing if we just had 'execute'. >> >> But this is unlikely to change ever. So here is how I understand it: >> >> - 'execute' always gets you into the next stage, and iff 'next' is an >> allowed action, then 'execute' is equivalent to 'next', or otherwise it >> is equivalent to 'complete'. > > From my reading, this is equivalent to what the standard already says and a > good clarification. +1 (also, I marked it editorial for that reason, if > anyone > is uncomfortable with that, let me know here, directly, on github or in > editor@). FWIW, I think this isn’t what the standard already says, although may be sensible. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] undefined state in XEP-0050
> On 21 Feb 2018, at 18:50, Florian Schmaus wrote: > > On 06.08.2015 17:42, Goffi wrote: >> G'day, >> >> there is a little issue with XEP-0050: in section 3.4 bullet 3, it's is >> said that when the element is present: >> >> - The action "execute" is always allowed, and is equivalent to the >> action "next". >> - The "next" action is typically the "next" button or option in a >> wizard. If is not contained by the , it is disabled. >> >> So if "next" action is disabled, execute is allowed but equivalent to a >> disabled action. >> >> I have had an issue which seems related to this confusion with SleekXMPP >> and Gajim: if the next action is disabled in sleekXMPP, Gajim still show >> the "execute" button, but a click on it result in an error, while the >> "finish" button act as expected. >> >> My guess is that "execute" should be equivalent to "complete" when >> "next" is not possible (but what if "complete" is disabled too ?). > > I think it is a little design weakness of XEP-0050: Ad-Hoc Commands that > we have 'next' and 'execute'. It appears the whole protocol would be > much simpler and less confusing if we just had 'execute’. Execute is convenient - it’s not an action of its own per se, it’s just saying which of the provided actions is used by default (e.g. will be run when the user hits Enter), but allowing it to be sent as an action= value could have been better thought-out, I suspect (even then, it’s useful for the first stage of the form). So I suspect the underlying issue described here is UIs wrongly showing independent buttons for Execute and whatever Execute should mean. > But this is unlikely to change ever. So here is how I understand it: > > - 'execute' always gets you into the next stage, and iff 'next' is an > allowed action, then 'execute' is equivalent to 'next', or otherwise it > is equivalent to 'complete’. I think that if we follow what 50 says, we actually reach the conclusion that if execute isn’t set on actions, it’s equivalent to next, which may be disabled. Which basically means that an actions list not including next and not including an execute value is saying “The default is next, and it’s disabled”, which is more or less a broken xep 50 command so the responder shouldn’t send it. Changing to have the default switch to complete if there’s no next is probably not harmful, although is a change in behaviour from what we have. I suggest the most helpful thing to do here is to add some additional text explaining that Execute shouldn’t be a button of its own in the UI, but is an indication of default, if people are misunderstanding that. If we do that, the point of changing default in the absence of next is less important, but I’m not opposed (it is a change in behaviour, though, so needs Council vote IMO). /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] undefined state in XEP-0050
On Mittwoch, 21. Februar 2018 19:50:17 CET Florian Schmaus wrote: > On 06.08.2015 17:42, Goffi wrote: > > G'day, > > > > there is a little issue with XEP-0050: in section 3.4 bullet 3, it's is > > said that when the element is present: > > > > - The action "execute" is always allowed, and is equivalent to the > > action "next". > > - The "next" action is typically the "next" button or option in a > > wizard. If is not contained by the , it is disabled. > > > > So if "next" action is disabled, execute is allowed but equivalent to a > > disabled action. > > > > I have had an issue which seems related to this confusion with SleekXMPP > > and Gajim: if the next action is disabled in sleekXMPP, Gajim still show > > the "execute" button, but a click on it result in an error, while the > > "finish" button act as expected. > > > > My guess is that "execute" should be equivalent to "complete" when > > "next" is not possible (but what if "complete" is disabled too ?). > > I think it is a little design weakness of XEP-0050: Ad-Hoc Commands that > we have 'next' and 'execute'. It appears the whole protocol would be > much simpler and less confusing if we just had 'execute'. > > But this is unlikely to change ever. So here is how I understand it: > > - 'execute' always gets you into the next stage, and iff 'next' is an > allowed action, then 'execute' is equivalent to 'next', or otherwise it > is equivalent to 'complete'. >From my reading, this is equivalent to what the standard already says and a good clarification. +1 (also, I marked it editorial for that reason, if anyone is uncomfortable with that, let me know here, directly, on github or in editor@). kind regards, Jonas signature.asc Description: This is a digitally signed message part. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] undefined state in XEP-0050
Le mercredi 21 février 2018, 19:50:17 CET Florian Schmaus a écrit : > But this is unlikely to change ever. So here is how I understand it: > > - 'execute' always gets you into the next stage, and iff 'next' is an > allowed action, then 'execute' is equivalent to 'next', or otherwise it > is equivalent to 'complete'. > > I've submitted https://github.com/xsf/xeps/pull/591 > > Discuss :) Nice to see this post is not forgotten even after years :) As XEP-0050 is a draft standard and widely deployed, I also think it is very unlikely that it is changed, so your proposition seems a reasonable fix. Goffi ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] undefined state in XEP-0050
On 06.08.2015 17:42, Goffi wrote: > G'day, > > there is a little issue with XEP-0050: in section 3.4 bullet 3, it's is > said that when the element is present: > > - The action "execute" is always allowed, and is equivalent to the > action "next". > - The "next" action is typically the "next" button or option in a > wizard. If is not contained by the , it is disabled. > > So if "next" action is disabled, execute is allowed but equivalent to a > disabled action. > > I have had an issue which seems related to this confusion with SleekXMPP > and Gajim: if the next action is disabled in sleekXMPP, Gajim still show > the "execute" button, but a click on it result in an error, while the > "finish" button act as expected. > > My guess is that "execute" should be equivalent to "complete" when > "next" is not possible (but what if "complete" is disabled too ?). I think it is a little design weakness of XEP-0050: Ad-Hoc Commands that we have 'next' and 'execute'. It appears the whole protocol would be much simpler and less confusing if we just had 'execute'. But this is unlikely to change ever. So here is how I understand it: - 'execute' always gets you into the next stage, and iff 'next' is an allowed action, then 'execute' is equivalent to 'next', or otherwise it is equivalent to 'complete'. I've submitted https://github.com/xsf/xeps/pull/591 Discuss :) - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] undefined state in XEP-0050
G'day, there is a little issue with XEP-0050: in section 3.4 bullet 3, it's is said that when the element is present: - The action "execute" is always allowed, and is equivalent to the action "next". - The "next" action is typically the "next" button or option in a wizard. If is not contained by the , it is disabled. So if "next" action is disabled, execute is allowed but equivalent to a disabled action. I have had an issue which seems related to this confusion with SleekXMPP and Gajim: if the next action is disabled in sleekXMPP, Gajim still show the "execute" button, but a click on it result in an error, while the "finish" button act as expected. My guess is that "execute" should be equivalent to "complete" when "next" is not possible (but what if "complete" is disabled too ?). Cheers Goffi
