Multimedia submissions [Was: HTML+ and automated forms ]

"Daniel W. Connolly" <connolly@hal.com>
Errors-To: listmaster@www0.cern.ch
Date: Mon, 27 Jun 1994 23:33:03 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406272130.AA00463@ulua.hal.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: connolly@hal.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Daniel W. Connolly" <connolly@hal.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Multimedia submissions [Was: HTML+ and automated forms ]
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas

In message <94Jun27.131346pdt.2760@golden.parc.xerox.com>, Larry Masinter write
s:
>We're looking for a way that a form can ask for the user to supply a
>'file', with full MIME typing associated with that file, e.g., the
>form element would want to specify 'Accept:' headers. 

Ah... I hated the <INPUT TYPE=FILE> proposal, but I've been noodling
on your application, and now that you phrase the question this way, a
lightbulb just went off and I can see how I think it could work...

Let me preface this by saying that I still haven't made a complete
study of WWW forms -- for the HTML 2.0 spec, we did a cut-and-paste
job from the HTML+ spec and we consulted the NCSA doc a little. Since
then, several people have told me it's wrong, but nobody's provided a
replacement spec.

Anyway, that said..

I wonder if you could use the ENCTYPE attribute of the FORM element
to express what you're interested in...

My current revision of the html.dtd,
        $Id: html.dtd,v 1.16 1994/06/13 20:55:50 connolly Exp $
includes the following:

<!ATTLIST FORM
        ACTION %URI #REQUIRED
        METHOD (%HTTP-Method) #IMPLIED
        ENCTYPE %Content-Type; #IMPLIED
        >

So it is possible to express the content-type of the submitted
information. From the NCSA doc, I see:

From: http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/Docs/fill-out-forms/overview.html :
	ENCTYPE specifies the encoding for the fill-out form
	contents. This attribute only applies
	if METHOD is set to POST -- and even then, there is only one
	possible value (the default,
	application/x-www-form-urlencoded) so far.

While this doesn't really give you the full expressive power of
a set of Accept: headers, you could:

	1. Restrict your applications to one content type,
	possibly using the "text/*" convention.

	2. Hack and wedge more stuff in the ENCTYPE attribute

	3. Propose a new attribute or a subelement of FORM that
	gives the full expressive power of Accept:

	4. Punt the idea of sticking the Accept: info in the
	document, and have your client use a HEAD request
	to find out what forms of data are acceptible. This has bad
	performance implications for clients that want to change
	the user interface based on the acceptable content types.

>Personally, I like putting them in the form if only so that you could
>mail someone a form rather than always deliver it to them via http...

This proposal is happy in that respect.

>For example, if this were a fax service, it could Accept: text/*,
>application/postscript, image/* (but not, say, audio/*); if it were a
>answering-machine application, it might accept only audio/*.

To express these examples (using choice 2 above), you might use:

	<FORM ACTION="http://faxserverhost/faxinput" METHOD="POST"
		ENCTYPE="text/*, application/postscript, image/*">
	Please submit your fax data.
	<INPUT TYPE=SUBMIT>
	</FORM>

	<FORM ACTION="http://ansmachhost/audioinput" METHOD="POST"
		ENCTYPE="audio/*">
	Please submit your message.
	<INPUT TYPE=SUBMIT>
	</FORM>

The client would, of course, have to recognize the ENCTYPE="..."
and modify the user interface accordingly.

Dan