Re: QueryForms and Input tag

Dan Connolly <connolly@pixel.convex.com>
Message-id: <9301200901.AA11039@pixel.convex.com>
To: Dave_Raggett <dsr@hplb.hpl.hp.com>
Cc: www-talk@nxoc01.cern.ch
Subject: Re: QueryForms and Input tag 
In-reply-to: Your message of "Tue, 19 Jan 93 15:59:34 GMT."
             <9301191559.AA05466@manuel.hpl.hp.com> 
Date: Wed, 20 Jan 93 03:01:36 CST
From: Dan Connolly <connolly@pixel.convex.com>


>I like the idea, and am glad to see people are now taking an interest in html
>and forms.

Does this mean my wag at an example does jive with your ideas? I'm
still not clear... especially on the protocol.

>Summarising what you suggest above:
>
>    <input name=FIELDNAME type=FIELDTYPE [width=FIELDWIDTH] [help=HELPUDI]>
>
>    FIELDNAME is a unique identifier for this form
>    FIELDTYPE ::= "boolean" | "text" | "integer" | "float"
>
>    The [ ] brackets denote optional attributes.

Why not let's talk SGML, while we're at it? It's not so tough:

<!ENTITY % url "CDATA" -- this is kind of a DTD macro >
<!ELEMENT input - O EMPTY>
<!ATTLIST input
	name ID #REQUIRED
	type (boolean|text|integer|float) #REQUIRED
	help %url; #implied
	>

>Multiple choice items need a richer structure, e.g.
>
>    <select name=FIELDNAME type=CHOICETYPE [value=VALUE] [help=HELPUDI]>
>        <choice>item 1
>        <choice>item 2
>        <choice>item 3
>    </select>
>
>    CHOICETYPE ::= "radio" | "single" | "multiple"

<!ELEMENT select - - (choice+)>
<!ATTLIST select
	name ID #REQUIRED
	type (radio|single|multiple) #REQUIRED
	value IDREF #IMPLIED -- defaults to first choice --
	help %url; #IMPLIED
	>
<!ELEMENT choice - - (%hypertext)+ -- see HTML DTD: text with A tags -->
<!ATTLIST choice
	id ID #IMPLIED -- select's value attribute points here --
	value CDATA #IMPLIED -- defaults to element content --
	>

>It is also useful to distinguish form decorations from output fields. I think
>this can be adequately handled using the existing emphasis tags though.

I don't get it; what's an output field?

>How will the <queryform> tag take over from the <ISINDEX> mechanism? Right
>now, the browser provides an input field and search button, but I assume that
>in future, searchable documents will use the queryform approach instead.
>
>Forms generally involve additional ideas:
>
>    a)  expressions and queries for output fields
>
>    b)  edits (constraints) on input field values
>
>    c)  dependencies between fields
>
>These can all be handled by the server, albeit with a performance penalty as
>perceived by the user.

Whoa! You mean there's a round trip every time the user enters a field?
This implies a stateful connection between the client and server.

This isn't the model I had in mind at all! I thought it went:
	* server sends whole form
	* user interacts with client only to fill out form
	* user instructs client to send completed form to server
	* client translates user inputs using <QUERYFORM> element
	  and sends results to server in HTRQ data
	* server processes query.

Dan