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

Thomas Muldowney temas at box5.net
Fri Mar 15 05:33:57 UTC 2002


Rebuttals and thoughts thruoghout:

On Thu, Mar 14, 2002 at 04:27:14PM +0100, Max Horn wrote:
> 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.
> 

I disagree.  The value ends up as a string when it's sent to the server,
and adds too much checking on the client side.  None of the other types
contain typed value and once we allow one such as number, what's to stop
us from wanting masking for strings?
> 
> 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.
> 

Again, I have to disagree.  Why would the user ever see this out of
order, and the spec clearly indicates that the questionning is in order?  In 
almost any logical display manner I can think of all the
fields would be present, or shown to the user sequentially.  Just to
make sure we're on the same page I'm thinking of these views as
"logical" ones:
    - Single dialog
    - Sequential questioning
    - Wizard

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

I can see your point, and the solution makes sense, but there are logical uses 
for fixed. There may be need/want for an ad in the middle of the survey,
or maaybe a message of thanks at the end, so it's hard to just completely 
remove it. The problem is, if the field is there, how do you stop abuse?

Ryan was just telling me that we can word the JEP to state it should not
pertain to a single field, and <desc> should be used for that.  That way
it could be used to mark groupings or something of that nature.

The <desc> field is being adding in.

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

I think your other post adequately covers this, and we can fully support
whatever solution we find.

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

Noted


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

I guess this is a wording issue about not supplying the <value/>.  It
will be clarified.


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

Ryan and I have argued/pondered this one for a while now.  It could be a
list-single but that does not provide for many situations which really
are a 1/0, true/false, yes/no, or other "checkbox" things.  That's
actually exactly why it was added.  The reasoning for the options and
values is something similar to HTML forms, it allows for a bit more
reasonable information to be associated with the value.  The first
option would be the "on", "1", "true" value, and the other the negative.
Any other major thoughts on this?


That should do it.


--temas



> 
> 
> 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
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20020314/8f1b5b6f/attachment.sig>


More information about the Standards mailing list