[standards-jig] extending disco#info result

Richard Dobson richard at dobson-i.net
Wed Feb 25 15:41:13 UTC 2004

> 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.


More information about the Standards mailing list