[standards-jig] jep-0004 - jabber:x:data

Max Horn max at quendi.de
Thu Mar 14 15:27:14 UTC 2002


I am refering to http://www.jabber.org/jeps/jep-0004.html, version 1.4.

Some things I'd like to note:


I) Besides the suggested fields, it would be good to have an 
additional, "number". Nomrally it would allow any number, but it 
should have the following additional (optional) attributes:
  - min value
  - max value
  - isInteger (normally, it's float)

Numeric input is required for many applications, and this should 
cover most uses.


II) One should always keep in mind the different devices such a 
x:data query could be handled on, and the different ways they would 
be presented to a user. This has to be possible on pure textual 
clients as well as graphical ones; on full blows PCs or on cellulars, 
etc. Each has different limitations/possibilities. Ideally, we want 
to avoid limiting the usage of x:data to only a subset of these 
devices, hence we should keep this in the back of our heads...

More concrete, I don't like example 2 at all for this reason, for 
multiple reasons:
  1) It assumes sequential processing. This might be true on say a 
command line client, or on a cellular where there is not enough space 
to display everything at once. But in a GUI client (or a curses based 
CLI client), one probably will try to fit this stuff into one dialog 
(possible one with multiple tabs). Read: the user can and will 
process this out of order. But the phrasing of example 2 ("Now please 
give us some information about your Blood.") strongly indicates 
sequential processing. Not only would that be bad for a real world 
usage of x:data, it can also mislead implementors reading the 
examples. Conclusion: the example 2 shouid be reworked.


  2) It abuses the "fixed" type field as a descriptions for other 
fields. While at first it might seem cute to do it this way, since we 
don't need additional defintions, I think it is a bad idea. A client 
can't know when a fixed field is associated this way to a following 
field. This poses a problem if for example screen space is heavily 
limited. Think of a cellular, it may not be able to display the 
description and the field at once, so it might want to offer a "help" 
soft key which shows the description.
Hence, I think descriptions should be part of the field, leaving it 
to the client how to present this (before or after the actual field; 
as a tooltip; etc.), possibly with some additional hinting 
(description style text vs. instruction style).
To clarify what I mean, consider this excerpt from example 2:

       <field type='fixed'>
         <value>Now please give us some information about your Blood.</value>
       </field>
       <field type='list-single' label='Blood Type' var='blood_type'>
         <required/>
         <value>a+</value>
         <option label='A-Positive'><value>a+</value></option>
         <option label='B-Negative'><value>b-</value></option>
         etc...
       </field>

I'd prefer something like this:

       <field type='list-single' label='Blood Type' var='blood_type'>
         <required/>
         <desc>Please give us some information about your Blood.</desc>
         <value>a+</value>
         <option label='A-Positive'><value>a+</value></option>
         <option label='B-Negative'><value>b-</value></option>
         etc...
       </field>

In fact this addresses both issues I mentioned, since it also changes 
the desc phrasing to not imply sequential processing.


III) Internationalisation & Localization

While Jabber in theory is well prepared for this, as it uses unicode 
for all communication, sadly it's greatly lacking in this area 
currently. Don't make the same mistake with x:data, design I18n into 
it form the beginning. Each form should have a way to specify in 
which language it is written. Also, users should have the ability to 
specify in theiry queries a list of prefered languages.
This way, a french user can get a french form, if available, and a 
german user a german one, etc.

Of course, this is something that has to be addressed for the whole 
of Jabber soon. Like, a user should be able to specify at login time 
the list of prefered localizations. This is an important issues and 
should be discussed seperatly I guess and another JEP written for 
this. I'll write a seperate posting on this topic.



IV) A phrasing change suggestion: instead of this:

>At this point the client has three choices.
>
>1) It can not support the jabber:x:data methodology.
>...

It has the choice of not supporting - that is a bit misleading, since 
this also covers older clients that simply were written before this. 
So maybe write this:

>There are three possibilities how a client could handle this.
>
>1) The client does not support the jabber:x:data methodology.
>...



V) It must be possible to explicitly *not* give a default value for a field.
It's not clear from the examples to me that this is the case.
This is important, since for some things there just are no sane 
default values (like for names)

VI) For boolean fields, do you just assume the first given option 
corresponds to true, the second to false? Actually, I don't see at 
all how "boolean" differs from "list-single", it's just a list with 
exactly two items.
When I think of a type boolean field, I think: "A field that a GUI 
client could represent with a checkbox". That's not possible with the 
current proposal.

So, my suggestion is to replace this:

       <field type='boolean' label='Willing to donate' var='willing'>
         <value>yes</value>
         <option><value>yes</value></option>
         <option><value>no</value></option>
       </field>

with something like this:

       <field type='boolean' label='Willing to donate' var='willing'/>

A text client would simply ask the user for yes/no, as before; a GUI 
client could use a checkbox, etc.. The returned value would be 0 and 
1 (or false and true if that is preferable)

And if somebody really wants a certain text choice, they can use 
list-single for the exact same effect



Overall, I think x:data is a step in the right direction, and a very 
importent center piece for jabber. It's important to do this right, 
but also to get it done soon, so that clients/services can implement 
it. Thanks to reatmon, jer and temas for starting it.


Cheers,

Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890



More information about the Standards mailing list