[standards-jig] Multi-stage conversations & jabber:x:data

Ryan Eatmon reatmon at jabber.org
Mon Sep 9 19:08:22 UTC 2002

Actually... I'm going to disagree that Jabber and x:data don't provide 
this functionality right now...

Much like the web, Jabber is somewhat stateless when it comes to 
transactions.  A user requests a register form, they get it.  Sometime 
later they fill it out, and get an answer.  All state information has to 
travel with the form.  Just like a web form.  When the form gets 
submitted the thing receiving the form can pull anything out and 
recreate any state that is needed.

You can do the same thing with x:data and hidden fields.  In much the 
same way that you have to create this type of thing in PHP, it is up to 
the Component author to build this into the Component.

Here's an example transaction:

U(ser): request form
C(omponent): send form with hidden field containing a key
U: fills out form and submits
C: reads form, gets key.  Creates next form based on data in the form, 
sends a new form to the user.
U: fills this form out, and submits it.
C: reads form, gets key.  Creates next form based on data in the form, 
sends a new form to the user.
U: fills this form out, and submits it.
C: accepts final form and sends the final type='result' <query/> packet.

The trick to doing this, is that a client has to render any and all 
forms that it gets.  This is the hard part of making this a standard 
flow.  Getting all of the Clients on board.

Jeremy Nickurak wrote:

> [14:31] <pgmillard> x:data RULES
> [14:31] <pgmillard> it's going to revolutionize jabber IMO.
>I too think that jabber:x:data has an incredible amount of potential,
>but there's still a hopefully minor speedbump to be addressed: Neither
>jabber nor x:data provides a means for building a dynamic
>back-and-forth discussion of questions and answers, that results in a
>particular action, for example, a jabber:iq:register submission.
>Let me illustrate using a simple, real-life example: As you may have
>noticed, many web registration systems have broken their registration
>process up into a number of stages, for example, a first stage where
>you enter your name, country, and age, and a second stage, which asks a
>number of questions, which may vary slightly depending on your
>responses to the first stage. For instance, a choice of a particular
>country could result in the registration system prompting the user for
>a province or state. While the implications of that particular case are
>fairly limited, the dependance on the age may be more important: COPPA
>(the Children's Online Privacy Protection Act) for example, may
>actually make certain questions illegal to ask on the basis of age.
>This is precisely why such web registration systems will avoid asking
>those questions in the second stage, if the first stage answers match
>certain criteria.
>Web forms are able to cope with this problem, because they represent
>very (,very, very) unstructured dialogs. Jabber and jabber:x:data,
>conversely, aim to present a conversation so structured that they can
>actually be applied to GUI interfaces (if the client software so
>chooses). However, the traditional set of jabber conversations,
>jabber:iq:register and jabber:iq:search to name two, follow a very
>strict series of events: An empty IQ-GET, a IQ-RESULT with a series of
>fields, a IQ-SET to provide the input, and an IQ-RESULT to verify the
>reciept and processing of the input. Nowhere in this process is there
>room for one or more extra sets of questions, and one or more 
>orresponding sets of answers.
>Pgmillard suggested the following series of events as a solution:
>CLIENT:	iq-get xmlns="jabber:iq:register"
>SERVER:	iq-result xmlns="jabber:iq:register" + x:data
>CLIENT:	iq-set xmlns="jabber:iq:register" + x:data
>SERVER:	message, x:data
>CLIENT:	message, x:data
>In this case, additional dialog would occur in the series of
><message>'s following the standard iq GET:RESULT:SET:RESULT dialog,
>with a couple of complications:
>1) Something needs to be available in the accompanying <message> tags
>to associate the exchange of data there with the previous exchange of
>data in the IQ GRSR process, I think. Because jabber is asyncronous, we
>can't rule out the possibility that more then one of these
>registrations may be occuring simultaneously, and a cue of some kind
>that relates the <message>'s to the <iq>'s would be neccesary to keep
>that clear in the client's interface. Pgmillard suggested the use of
><thread>'s in the <message>'s, but we would still need a standard place
>within the IQ exchange in which this would be placed. Definitely some
>possibilities there.
>2) The last RESULT in GET:RESULT:SET:RESULT has an abiguous meaning: In
>the above discussion, it's absent, because the discussion is does not
>even end with the final IQ. Obviously this would be a problem for
>clients that will expect a final RESULT to complete the discussion.
>Likewise, a client could easilly see the final RESULT, and infer that
>the registration process was completed successfully, when clearly it
>was not. A solid association between the IQ and message portions of
>the discussion (as above) may clear at least some of this up.
>Personally, I'm fond of another solution entirely: another iq type,
>"prompt" (name up for debate of course). This would allow the creation
>of more extensive IQ discussions, for example,
>GET:PROMPT:SET:PROMPT:SET:RESULT, in which the first prompt & set could
>provide the first stage questions and answers, and the second prompt &
>set could provide the second stage questions and answeres. Such a
>dialog could go on extensively, depending on the requirements of the
>particular component in question. The simplest reason I believe this is
>correct, is that "result" has associated with it the concept of the end
>of a task, whereas in the traditional IQ conversation it is used as
>both the beginning and end of a component's role in the conversation.
>A similar solution might involve flagging the final IQ result of the
>conversation ("Over and out.")
>Either one of these solutions would address the issue of multi-stage
>discussions as far as I can tell, with a few obvious problems to
>address (Can a new IQ-type be justified at this time? Is a dialog split
>across IQ's and message's awkward?).


Ryan Eatmon                   reatmon at jabber.org 
Jabber.org - Perl Team    jid:reatmon at jabber.org

More information about the Standards mailing list