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