[standards-jig] JEP-004 Comments

Jeremy Nickurak atrus at jabber.spam.rifetech.com
Sun Jul 21 20:30:01 UTC 2002


I was very curious when I first heard about JEP-004, as it seems to
solve nicely a few of the problems I've been dealing with. Defining data
without going so far as to specify layout, while still addressing the
various types of data that may be involved, is almost exactly what I was
looking for.

However, I'm wondering if it might be useful for jabber:x:data to
provide some abstract hints about the organizational structure of that
data as well. For example, in specifying one's location, the exact set
of fields could vary significantly from one country to another. This
should be relatively easy to represent by nesting fields inside of the
relevant options:

<iq type='result' from='census.jabber.org' id='data1'>
  <query xmlns='jabber:iq:register'>
    <instructions>
      You need a forms capable client to register, or you need
      to visit the URL to fill out the form.  http://.........
    </instructions>
    <x xmlns='jabber:x:data'>
      <instructions>
        Welcome to the 2002 Jabber Civic Census.
      </instructions>
      <field type='hidden' var='form_number'>
        <value>113452</value>
      </field>
      <field type='fixed'>
        <value>We need your contact information.</value>
      </field>
      <field type='text-single' label='First Name' var='first'>
        <required/>
      </field>
      <field type='text-single' label='Last Name' var='last'>
        <required/>
      </field>
      <field type='text-single' label='Jabber ID' var='jid'>
        <required/>
      </field>
      <field type='list-single' label='Gender' var='gender'>
        <value>male</value>
        <option label='Male'><value>male</value></option>
        <option label='Female'><value>female</value></option>
      </field>
      <field type='list-single' label='Country' var='country'>
        <option label='Canada'><value>canada</value>
          <field type='list-single' label='Province' var='province'>
            <option label='B.C.'><value>bc</value></option>
            <option label='Alberta'><value>alberta</value></option>
            <option label='Saskatchewan'><value>sask</value></option>
            <option label='Manitoba'><value>manitoba</value></option>
            <option label='Ontario'><value>ontario</value></option>
            <option label='Quebec'><value>quebec</value></option>
            <option label='New Brunswick'><value>nb</value></option>
            <option label='Nova Scotia'><value>ns</value></option>
            <option label='PEI'><value>pei</value></option>
            <option label='Yukon'><value>yukon</value></option>
            <option label='North West
Territories'><value>nwt</value></option>
            <option label='Nunivit'><value>nunivit</value></option>
          </field>
	  <field type='text-single' label='Postal Code' var='postalcode'/>
        </option>
        <option label='United States'><value>us</value>
          <field type='text-single' label='State' var='state'/>
	  <field type='text-single' label='Zip Code' var='zipcode'/>
        </option>
      </field>
    </x>
    <x xmlns='jabber:x:oob'>
      <desc>Web form for registering with the Jabber Census</desc>
      <url>http://.......</url>
    </x>
  </query>
</iq>

Likewise, a transport registration could present a user with multiple
sets of fields based on what's required:

<iq type='result' from='aim.jabber.org' id='data2'>
  <query xmlns='jabber:iq:register'>
    <instructions>
      You need a forms capable client to register, or you need
      to visit the URL to fill out the form.  http://.........
    </instructions>
    <x xmlns='jabber:x:data'>
      <instructions>
        Please enter an AIM screen name & password and or an ICQ UIN and
password.
      </instructions>
      <field type='boolean' label='Connect to AIM' var='aim'>
	<option><value>1</value>
	  <field type='text-single' label='AIM Screen Name' var='aimid'/>
	  <field type='text-private' label='AIM Password' var='aimpassword'/>
	</option>
      </field>
      <field type='boolean' label='Connect to ICQ' var='icq'>
	<option><value>1</value>
	  <field type='text-single' label='ICQ UIN' var='icqid'/>
	  <field type='text-private' label='ICQ Password' var='icqpassword'/>
	</option>
      </field>
    </x>
  </query>
</iq>

None of this specifies the specifics of the layout and presentation of
these choices of course. Different clients would be free to 'grey-out' a
section of options if in a graphical environment, or use tabs for large
co-existant groupings. This extension would be particularly useful I
think in console or speach recognition environments, where a client
would otherwise have to prompt for known superflous values.

The response could either be made mandatorilly nested, (which would
avoid any potential variable name conflicts), or the spec could simply
specify that all variables are globally scoped.

Any comments? Is this something people could realistically see
themselves working into a component or client?

-- 
Jeremy Nickurak -= Email/Jabber: atrus at rifetech.com =-
"You know, Hobbes, some days even my lucky rocketship 
 underpants don't help" -- Calvin



More information about the Standards mailing list