> Why not let's talk SGML, while we're at it? It's not so tough:
You're on!
-------------------------------------------------------
<!-- The following defines the <input> tag with the attributes:
name (required)
unique name used to identify field to server
type (required)
indicates type of input value (boolean, text, integer, float)
width (optional, defaults to 20)
width for field in terms of average char width
browsers should allow users to type up to this number of chars
and no more (except for dealing with control keys e.g. backspace)
value (optional, defaults to null or "")
initial value to display in the input field
ok (optional, defaults to yes)
when no, signifies that the current value is in error.
enabled (optional, default to yes)
when no, prevents user from changing this field's value
help (optional, default provided by application)
a URL which would provide explanatory information for this field
-->
<!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
width NUMBER "20"
value CDATA ""
ok (yes|no) "yes"
enabled (yes|no) "yes"
help %url; #IMPLIED
>
<!-- The following defines the <select> tag: -->
<!ENTITY SELECT - - (CHOICE)*>
<!ATTLIST select
name ID #REQUIRED
type (radio|single|multiple) #REQUIRED
value PCDATA ""
ok (yes|no) "yes"
enabled (yes|no) "yes"
help %url; #IMPLIED
>
<!-- The following defines the <choice> tag: -->
<!ENTITY % inline "EM | TT | STRONG | B | I | U |
CODE | SAMP | KBD | KEY | VAR | DFN | CITE " >
<!ENTITY % text - - "#PCDATA | %inline;">
<!ENTITY CHOICE - O (%text; | CHOICE)*>
<!ATTLIST choice
value PCDATA "" #REQUIRED
enabled (yes|no) "yes"
>
-------------------------------------------------------
>> 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
Oops! crossed wires - I intended just what you say above. The performance
penalty as perceived by the user comes from having to send the complete form
to find out that s/he has mistyped one of the fields.
A smarter/more sophistocated system would include scripts as part of the
queryform document, which apply the constraints locally WITHOUT any network
delays.
BUT that seems too complex for us to put in HTML for now!
Note that work at ETSI (European Telecommunications Standards Institute) on
hypermedia/multimedia standards for ISDN sees scripts as an essential element
for multimedia, and smart documents. Their work is being driven by the
European telecomms companies plus a few multimedia specialist companies, and
seems obsessed with videotex, and complex ISO multilayed standards.
Mail me if you are interested in references to this work.
Best wishes,
Dave Raggett