Re: QueryForms and Input tag

• Mail folder: WWW Talk Jan-Mar 1993 Archives
• Next message: Jim Davis: "EDI for forms?"
• Previous message: Dave_Raggett: "Re Re HTML and Lists"

Date: Wed, 20 Jan 93 18:16:21 +0100
From: Tim Berners-Lee <timbl@www3.cern.ch>
Message-id: <9301201716.AA05229@www3.cern.ch>
To: Dan Connolly <connolly@pixel.convex.com>
Subject: Re: QueryForms and Input tag 
Cc: Dave_Raggett <dsr@hplb.hpl.hp.com>, www-talk@nxoc01.cern.ch
Reply-To: timbl@nxoc01.cern.ch

A few unrelated points about this.

A. There is a whole standard, as yukky as SGML, on Electronic data  
Intercahnge, meaning forms and form submission.  I know no more
except it looks like fortran backwards with no spaces.
But it might be interesting for a set of featuire to be supported.

B. I see a need for the definition os two things, a form to be filled  
out 9containing field types and constraints), and a format for the  
return of the field values. The latter is a structure of typed values  
(parameters) plus a note of the method to be applied and the object  
to which it is to be appllied. (I can see several different forms  
providing the same structure, for example a simpler form with a lkot  
of default values, and a separate one in French, all targetted at the  
same object).

I don't think the form should contain a macro for generting a query  
in an arbitrary language. That is too open-ended a function. I think  
the server should be responsible for taking a structure of field  
values and applying it to an object.

I'd like to see this generalised. In HTTP2, an object may allow a  
large set of operations. For each operations, one ought to be able to  
retrieve a form for filling out the parameters. The guts of this form  
should be no less than a complete parameter definition for the  
method. Of couse a general method returns a structure of results as  
well (rather than always a document).

I  see the following scenario:

1.	user follows a link to an object, a flight description, say
2.	The flight object has in its HTTP2 Allowed: field the
	Method RESERVE. The client program doesn't understand this
	but sticks it in the menu.
3.	The users wants to reserve a seat, and pulls down "RESERVE"
	from the menu.
4.	The client asks the server for a [set of] form[s] for which
	describe the parameters to the RESERVE method. The user may
	have to pick one.
5.	The user fills in the form.  The methodname RESERVE and the
	uri of the object he is operating on are supplied by the
	client software.
6.	Parameters (structure of field contents) , methodname and
	object uri are sent off to the server.
7.	A document is returned with the results.

The important thing is that we bridge the gap between automatic and  
manual procedures. Obviously, the user will soon be making local  
macros to reserve sets of flights for himself and his friends. So the  
guts of what goes on must be machine-understandable, not just  
human-readable.

Currently HTTP2 returns a MIME document. A MIME document can be a set  
of objects each with a Content-Type,  but it is kinda heavy for an  
array of 3 integers!  At this point, ASN/1 would seem a better bet (a  
rare thing! ;-) Perhaps we can look at a multipart message and a data  
structure in the same way with generality.

[A problem with including a more compact representation as part of a  
MIME document is that MIME doesn't like encoding techniques to be  
applied which hide the internal types from a MIME gateway. Therefore,  
one might just have to say there was a black box MIME object like

	Content-Type: application/ASN-1
	Content-encoding: base64

Of course ASN/1 like SGML requires a reference to the DTD equivalent
for the (numeric in this case) tag values.  What a plethora of choice  
we have with SGML, ASN/1, RCC822... Perhaps we can write  
architectural forms for DTDs which produce ASN/1-equivalent  
definitions, which will then allow the DTD to define the ASN/1 and  
ASN/1 to become a natural alternative syntax for any conforming DTD.
[It could (is?) done now, but the architectural forms would allow a  
field which is in fact an integer to be sent as an ASn/1 integer  
rather than as a bit of text]

In fact of course the form itself in fact contains a specification of  
the type of the field value structure, so from the form one can  
generate the DTD and/or ASN/1 description for the reply ... silly me.
In fact one can imagine the output data coming in the same way, as a  
set of field values plus a set of forms which would allow its display  
in various languages etc.  The specification of a method required  
just giving the URIs of the infput and output forms.

At any rate, I think it is important to differentiate the set of  
values from the form.

Tim