[standards-jig] extending disco#info result

Matthew A. Miller linuxwolf at outer-planes.net
Wed Feb 25 16:15:50 UTC 2004

First, allow me to apologize for not better annotating my example.

Here it is, including things that should have been there the first time:

<x xmlns='jabber:x:data' type='result'>
  <field var='FORM_TYPE' type='hidden'>
  <field var='muc#room_desc' label='Description'>
    <value>The place for all good witches!</value>
  <field var='muc#room_subj' label='Subject'>
    <value>The place for all good witches!</value>
  <field var='muc#room_occupants' label='Number of Occupants'>
    <validate xmlns='http://jabber.org/protocol/xdata-validate' 

This should translate to:

NAME                  | VALUE
Description           | The place for all good witches!
Subject               | Fire Burn and Cauldron Bubble
Number of Occupants   | 3

Second, I firmly believe JEP-0004 already allows for this behavior.  To 
start with, there is a "type" attribute on the containing element.  This 
type pretty clearly states whether the x:data is meant for completion 
(type='form'), for processing (type='submit'), for cleanup 
(type='cancel'), or for interpretation (type='result').  Also, JEP-0004 
does not specifically disallow this type of usage.  Many of the examples 
assume it will be used in a form/submit/result manner, but there is 
nothing stating that a 'form' MUST preceed a 'result'.

However, if the consensus is that JEP-0004 needs to change to reflect 
that, that can be accomplished.

-  LW

Richard Dobson wrote:

>>Just because my software doesn't understand what to do with the
>>particular fields within an x:data form (other than render them) doesn't
>>mean I don't understand what to do with it.
>>Building off the examples provided so far, let's say we get the form:
>>    <x xmlns='jabber:x:data' type='result'>
>>      <field var='FORM_TYPE' type='hidden'>
>>        <value>http://jabber.org/protocol/muc#room</value>
>>      </field>
>>      <field var='muc#room_desc'>
>>        <value>The place for all good witches!</value>
>>      </field>
>>      <field var='muc#room_subject'>
>>        <value>Fire Burn and Cauldron Bubble</value>
>>      </field>
>>      <field var='muc#room_occupants'>
>>        <value>3</value>
>>      </field>
>>    </x>
>>If my particular client turned this into some type of "properties" panel
>>or dialog to display to me, I would be able to tell that (in my
>>simpleton ways):
>>A)  The room is intended for all good witches
>>B)  They're currently burning and boiling stuff
>>C)  There's three "people" already there
>>My client may not know what to do other than display it.  However, I do
>>know what to do with this information, and I use it to aid me in
>>determining if I also want to enter the room.
>But again is there any "real" value in displaying the information if you
>cannot display it appropriately, using your example xml above it would
>display a rather cryptic list of things with titles like:
>muc#room_desc            The place for all good witches!
>muc#room_subject        Fire Burn and Cauldron Bubble
>muc#room_occupants    3
>This is hardly user friendly and from the xml above is the only possible
>generic property list you could display.
>>If we went with "custom" structures, my client would need to understand
>>it in order to display it.  If my software doesn't get it, I don't
>>either, even though I would "get it" better than most software would.
>Yes but to display it in any kind of real "usable" form you still need to un
>derstand the field vars, which is as good as understanding a namespace.
>Also looking back at the x:data spec the usage you suggest does not seem to
>be inkeeping with what the spec describes or was intended to do, i.e. to
>send the response list as you are doing in your example you have had to
>received a form to respond to, IMO x:data usage for this does not seen
>inkeeping with past usage of x:data or the protocols intended use, using
>x:data in this way just seems rather messy. If we really must define a
>generic extension mechanism for extra properties why dont we just do
>something simple and clean for this, not just trying to re-use something
>that doesnt seem really appropriate just for the sake of re-using it.
>Also IMO in order to use x:data in this manor it would seem the x:data spec
>needs to be updated to allow for this kind of usage, i.e. sending value
>results without first having received a form.
>Standards-JIG mailing list
>Standards-JIG at jabber.org

More information about the Standards mailing list