Re: FORM ENCTYPE=multipart/www-form (was: Toward closure on HTML)
weber@eit.COM (Jay C. Weber)
Errors-To: listmaster@www0.cern.ch
Date: Wed, 6 Apr 1994 19:38:06 --100
Message-id: <9404061735.AA02880@eit.COM>
Errors-To: listmaster@www0.cern.ch
Reply-To: weber@eit.COM
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: weber@eit.COM (Jay C. Weber)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: FORM ENCTYPE=multipart/www-form (was: Toward closure on HTML)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 1149
> From: Dave Raggett <dsr@hplb.hpl.hp.com>
>
> My thoughts on a multipart/related format for forms are to start with
> an SGML based encoding for most fields and to use additional parts
> as needed for data which doesn't fit neatly into the SGML scheme, e.g.
> audio, pen input (as JOT), and file data. This way you normally just
> see one part.
>
> The next step is to define the SGML DTD for form contents and to
> specify the naming scheme for referencing data in other parts.
> The SGML ID notation springs to mind here.
Oh yeah, I forgot to mention that if someone wants to invent another
ENCTYPE, say text/sgml-www-form, then you can just use that as the
catch-all content-type instead of application/www-form-url-encoded.
But I guess the strong version of your thoughts is to require this new
SGML-based simple form value type, and bury www-form-url-encoded in
history.
I'm sure there are others who'll say "sure that would have been more
elegant, but why invent a new simple form format at this point?"
For my part, I like having the MIME encapsulation support either, then
we'll see what happens when the developers have at it.
Jay