Rayo complete reason changes

README.md

It is proposed that the <success/> element, indicating that a component completed successfully, be replaced by a set of more descriptively named elements, such as <initial-timeout/>, <end-of-file/>, etc. These allow the client to correlate the actual completion reason with what are potentially a large set of possible triggers from the original command. For example, setting both max-time and interrupt-on on an Output results in an ambiguous <success/> reason. In the case of Input, <success/> will be renamed <match/>.

Further, it is concerning that node ordering is still being relied upon for disambiguating children of <complete/>. Currently, the Record component may submit a complete event like this:

<presence to='[email protected]/1' from='[email protected]/fgh4590'>
  <complete xmlns='urn:xmpp:rayo:ext:1'>
    <success xmlns='urn:xmpp:rayo:record:complete:1'/>
    <recording xmlns='urn:xmpp:rayo:record:complete:1' 
         uri="file:/tmp/rayo7451601434771683422.mp3"
         duration="34000"
         size="23450"/>
  </complete>
</presence>

If a Rayo server were to instead spit out this event:

<presence to='[email protected]/1' from='[email protected]/fgh4590'>
  <complete xmlns='urn:xmpp:rayo:ext:1'>
    <recording xmlns='urn:xmpp:rayo:record:complete:1' 
         uri="file:/tmp/rayo7451601434771683422.mp3"
         duration="34000"
         size="23450"/>
    <success xmlns='urn:xmpp:rayo:record:complete:1'/>
  </complete>
</presence>

merry hell would break loose in clients. I strongly believe it is unacceptable to rely on the order of sibling nodes to provide any semantic value. Unfortunately, we currently have no other way of disambiguating a completion reason from any other child element. There are a few possible solutions to this:

1. Make the reason an attribute of <complete/>, and force any further meta-data to be included as children. [PREFERRED]
2. Mandate that the ONLY allowed child of <complete/> be the reason for completion, and any meta-data (such as recordings) be nested within the reason element.
3. Introduce a generic <reason/> element with a child such as <timeout/>.

I agree that ordered elements is not a big deal. From a server implementation perspective, it matters little how the event is formatted so go with whatever makes client implementation easy and doesn't mess up the schema.