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

Jeremy Nickurak atrus at jabber.spam.rifetech.com
Mon Sep 9 01:40:13 UTC 2002

 [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?).


Jeremy Nickurak -= Email/Jabber: atrus at rifetech.com =-
"Whoever fights monsters should see to it that in the process he 
 does not become a monster.  And when you look into an abyss, the
 abyss also looks into you." -- Friedrich Nietzsche

More information about the Standards mailing list