[standards-jig] jep-0004 - jabber:x:data
reatmon at ti.com
Fri Mar 15 14:40:54 UTC 2002
I'm writing this from work, so please excuse any formatting/threading
>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
I would go farther and argue that this is the design decision behind
Jabber. Keep all of the hard work on the Server, and make Clients
simple. I know that some people do not like this model, but it is a
very very clean model and makes it much simpler for someone to write
their own client.
>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?
Nothing stops it, put that in the new <desc/> tag and then the server
will send back the form with an error message stating that you goofed up
and selected too many items. Remember... this is not a GUI spec. This
is just a way to ask for data.
>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
We can do that.
>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).
No, because this is not a GUI spec. You can accomplish that by putting
in a list-single AND and text-single. Then saying in the instructions
to pick one, or pick the Other entry and put a value into the Other
question. Of course, this assumes that you are presenting the questions
>> > 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 =).
I've disagreed with a lot of what has gone into Jabber. =P
>> 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?
JEP-0004: Section 3.2
Also, the order that the fields/questions are asked in are based on the
order from the XML.
>> 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.
How does the user *not* see them sequentially? Who is used to starting
at the bottom of a form and working their way up? Who starts on the
last page of a book and reads backwards? Who fast forwards to the
middle of a movie and enjoys watching things out of order? You might be
able to get a handful of people state that they work that way, but the
majority of the world prefers things to be in a logical order. While
they may not admit it, they prefer things being organized.
>> 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)
The model we used to define this was based on the person who walks up to
you in the mall, calls you on the phone, or mails you a letter and asks
you to fill out a survey. They ask you the questions in order. Human's
process things top to bottom and in order. Yes, you can fill out a
question before another one, but you are still processing the entire
survey in order in your brain. At no point in time, at least in my
experience, have you been given something to fill out that was not
*presented* to you in an order.
Just to squelch this point being made... We used to have an order='x'
attribute on the fields, but realized that is was redundant since you
should base it off of the order of the fields in the XML.
>> > 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.
Ok... I had a lot of comments on this one... Typed them in. Read
them. Reread them. Reread the JEP. Deleted everything I spent 30
I think you were right the first time. It is trivial for the asker to
convert a 1/0 to what they want. So, I'm going to move the boolean to
<field type='boolean' label='Willing to donate' var='willing'/>
or with default:
<field type='boolean' label='Willing to donate' var='willing'>
I'm also going to add in a section to clarify that the only valid option
for boolean is 0 or 1.
Ryan Eatmon reatmon at ti.com
High Performance Analog EDA Core Team
More information about the Standards