Re: INPUT tag (was: Searching)

Dan Connolly <connolly@pixel.convex.com>
Message-id: <9301190637.AA19993@pixel.convex.com>
To: jim@wilbur.njit.edu (Jim Whitescarver)
Cc: TONYJ@scs.slac.stanford.edu, al@eies2.njit.edu, cis!bieber@dxmint.cern.ch,
        murray@eies2.njit.edu, reddy@wilbur.njit.edu, roxanne@eies2.njit.edu,
        www-talk@nxoc01.cern.ch
Subject: Re: INPUT tag (was: Searching) 
In-reply-to: Your message of "Sat, 16 Jan 93 13:26:25 EST."
             <9301161828.AA08431@njitgw.njit.edu> 
Date: Tue, 19 Jan 93 00:37:01 CST
From: Dan Connolly <connolly@pixel.convex.com>


>We may create a default text to be used with the comment feature, which
>will give all input/var field values in rfc822 style for mail based submission
.
>
>At issue are:
>
>- handling typed inputs, including texts.
>- applying inputs to search defaults. positional? named? override mech?
>- applying inputs to go to defaults?
>- getting data from users environment, e.g. users mail address.
>- how the fields will be substituted into hrefs within the sgml context. scope
?
>- saving updated input values in bookmarks?
>- communicating variables to activity scripts. (our "do" choice)
>
>We need a mechanism to assign arbitrary attributes to anchores and documents.
>These may share name space with input variables and VAR tagged data.
>
>If the INPUT and VAR tags could assign an entity value that we can use as
>&name; within hrefs, that would serve us well enough.  But, is that legal sgml
?
>It will require a second html parse of hrefs when they are selected.
>
>Our expertise with sgml is limited-- we need a quick and dirty way to pass
>data to activity scripts.  We are far from being able to make a final
>proposal to the web community.  The minimal may be:
>
>Tag	Attributes
>
>INPUT	name, length, default, help
>VAR	name, timeout
>
>The default search would positionally concatonate inputs into keyword position
s.
>Documents containg VAR info would not be cached longer than timeout.
>
>It seems that there is interest in fully interactive hypermedia within the web
>context.  All proposals/feedback is welcomed.  Hopefully we can do it together

[I'm going over old mail, replying to stuff I missed. I confess I
can't make much of this sketch. But from what I understand...]

I need examples to help me think. Tell me if this example matches
your model:

The client C sends GET foo to server S. S returns:

<HEAD>
<TITLE>Search Template</TITLE>
<QUERYFORM base="medibase">diagnose condition where age is <recall name="age">
and symptoms includes (<if name="headache">headache</if>
<if name="blackouts">blackouts</if>)
</queryform>
</HEAD>
<BODY>
How old are you? <input name="age" type="number"
width="5" help="http:s/help/inputs#age">
<P>
Do you have any of the following symptoms?
<UL>
<li>headach? <input name="headache" type="boolean" width="3">
<li>blackouts? <input name="blackouts" type="boolean" width="3">
</ul>

The client displays the body of the document with a blank
for the age, and check-boxes for the symptoms, and a 
"query" button (similar to a "search" button in response
to <ISINDEX>). The user fills in the blanks and clicks
the query button. Then the client uses the QUERYFORM
to compose its query from the inputs. It sends

GET medibase HTRQ/1.0
Accept: text/plain

diagnose condition where age is 25
 and symptoms includes (blackouts).

to the server. The server performs the query on the medibase
database and returns some document.

Where does the volatile data (<VAR> stuff) come in?

This would require some additions to the DTD:

Inside HEAD, we'd allow QUERYFORM:
<!ELEMENT queryform - - (#PCDATA|recall|if|...)+>
<!ATTLIST queryform
	base CDATA #IMPLIED -- URL to search defaults to current doc --
	>
<!ELEMENT recall - O EMPTY>
<!ATTLIST recall
	name IDREF #required -- points to an input element -->
<!ELEMENT if - O (#PCDATA|if)+>
<!ATTLIST if
	name IDREF #required -- points to input element -->

Then inside BODY, we'd add the INPUT element:

<!ELEMENT input - O EMPTY>
<!ATTLIST input
	NAME ID #REQUIRED
	WIDTH NUMBER #IMPLIED
	DEFAULT CDATA #IMPLIED
	HELP CDATA #IMPLIED -- url of help info --
	>

This would require changes to both the server and the client,
but I don't see any way around that.

It's not a major change to HTML -- just a few more elements.
The way I suggest you associate input variables with things
in the query is through the ID/IDREF mechanism as above.

Does this jive at all with what you're thinking?

Dan