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

Max Horn max at quendi.de
Fri Mar 15 10:36:02 UTC 2002

At 23:33 Uhr -0600 14.03.2002, Thomas Muldowney wrote:
>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?

Hm, OK, that's a design decision - leave all validation completly to 
the server. That makes life easier for clients, definitly. Note that 
in any case, the server would have to check the string again, of 
course, since a user could be using telnet and give any reply, even 
illegal ones.

Although one could argue that the list-single and list-multi fields 
form a small exception here. And for list-multi, what stops me from 
asking to have a way to request the user pick between 2 and 4 items? 

Anyway. how about adding to 2.1 "Simplicity" to explicitly mention 
this. Something like following sentences: "As a consequence of this, 
e.g. field validation is left entierly to the component sending the 

BTW, do you plan on supporting combo-box style fields? I.e. like a 
list-single, only that clients should offer the user to pick values 
not in the list. (I don't say I particular want to see this feature 
in, just curious).

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

I have to disagree with your disagreement here =).

>   Why would the user ever see this out of
>order, and the spec clearly indicates that the questionning is in order?

Where exactly does the spec do that?

>   In almost any logical display manner I can think of all the fields 
>would be present, or shown to the user sequentially.

"Almost" doesn't mean all, I hope =). Plust, only because one can't 
think of something when one writes a spec doesn't mean it can't 
occur. A very simple example known by everybody are graphical 
dialogs. See, when I say "out of order", I didn't mean the client 
will ask the user the questions in a different order. I mean that the 
questions will be presented in a single dialog. And that means: out 
of order prorcessing by the user. Nobody stops me from first clicking 
the checkbox at the bottom, then filling in the edit field in the 
middle, and then to go do the rest from top-to-bottm.

In a single dialog, the user does not *see* the data sequential, 
hence the phrasing shouldn't be sequential.

>  Just to
>make sure we're on the same page I'm thinking of these views as
>"logical" ones:
>     - Single dialog
>     - Sequential questioning
>     - Wizard

So you say that you always meant the spec everything to be 
sequential. Then I have to ask you, why do you want to limit the 
protocol on purpose this way? What do you gain by this limitation? I 
only see an arbitrary restriction, to be frank, but I am sure you had 
your reasons, so please explain them (and write them into the JEP, to 
prevent such confusion in the future)

[...snipped suggestion to add a <desc> element to <field>...]

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

I never meant it to be removed. Secondly, you never can stop abuse 
completly. but only because you can't get rid entierly of it doesn't 
mean you should just give up completly.
It's the same with SSL support: yeah, it's not really secure if you 
don't use certs properly, and all your server talk SSL with each 
other as well, etc. etc. But for 80% of users that doesn't matter - 
they only want SSL to protect them from the casual packet sniffer 
sitting in the next office, and that works pretty damn well. So only 
becaue you can't stop everything, does that mean you should do 
nothing? I don't think so.

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

That sounds very reasonable.

>The <desc> field is being adding in.



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

Yes, I understand that it was added so that checkboxes can be used. 
But when you explicitly give a list of choices (yes/no, true/false, 
etc.), what is the purpose of this? A server component can always 
convert these into each other with virtually no effort.

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

I think the only possible reason for having this is an UI reason, for 
clients that can't do checkboxes, for example. They would use the 
yes/no as the choices offered to the user (and these could be 
localized just like the rest of the form). So, your real concern  is 
not the value, that can just always be 0 and 1 (or whatever we agree 
on). The question is how to label them. Depending on the order of the 
option fields is a bad idea, IMHO, because it's very easy to mix this 
up accidentally.

How about this (I don't claim it's perfect, either :-):

        <field type='boolean' label='Willing to donate' var='willing'>
          <on label="Yes">
          <off label="Yes">


Max Horn
Software Developer

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

More information about the Standards mailing list