Difference between revisions of "XEP-Remarks/XEP-0050:Ad-Hoc Commands"
(Add Category) |
|||
Line 1: | Line 1: | ||
{{remarks}} | |||
== Undefined Sate, contradiction regarding execute, execute as attribute and action == | == Undefined Sate, contradiction regarding execute, execute as attribute and action == | ||
Line 35: | Line 37: | ||
There are currently at least two PR which try to improve the situation, an overview is given in https://github.com/xsf/xeps/pull/591#issuecomment-373313491 | There are currently at least two PR which try to improve the situation, an overview is given in https://github.com/xsf/xeps/pull/591#issuecomment-373313491 | ||
Latest revision as of 20:41, 17 April 2020
This is a page for information about XEP-Remarks/XEP-0050:Ad-Hoc Commands, including errata, comments, questions, and implementation experience. |
Undefined Sate, contradiction regarding execute, execute as attribute and action
There is a little issue with XEP-0050: in section 3.4 bullet 3, it's is said that when the <actions/> 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 <next/> is not contained by the <actions/>, 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 ?).
Original standards@ post: https://mail.jabber.org/pipermail/standards/2015-August/030137.html
Contradiction
Part of this confusion is that XEP-0050 makes multiple statements about execute (both the attribute and the action):
In 2.4.2: "The "execute" attribute defines which of the included actions is considered the equivalent to "execute" for this stage."
In 3.4: "If the <actions/> possesses the "execute" attribute, that value is the default button or option. If the <actions/> does not possess the "execute" attribute, there is no default button or option." and "The "execute" attribute SHOULD NOT specify a value that does not match one of the allowed actions." and, talking about the action: "The action "execute" is always allowed, and is equivalent to the action "next"."
In 4.2: "The "execute" attribute specifies what the action "execute" is equivalent to."
Clearly the statements "The "execute" attribute specifies what the action "execute" is equivalent to." (in 4.2) and "The action "execute" is always allowed, and is equivalent to the action "next"." (in 3.4) contradict each other.
There are currently at least two PR which try to improve the situation, an overview is given in https://github.com/xsf/xeps/pull/591#issuecomment-373313491