[standards-jig] jep-0004 - jabber:x:data
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
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
> - 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>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
How about this (I don't claim it's perfect, either :-):
<field type='boolean' label='Willing to donate' var='willing'>
email: <mailto:max at quendi.de>
phone: (+49) 6151-494890
More information about the Standards