> From: "Brian Gaines" <gaines@fsc.cpsc.ucalgary.ca>
>
> Root problem is that the client side is responsible for such
> matters of style and one is talking of features not
> standards. However, it would make more sense if the expected
> default behavior of a TEXTAREA was to wrap. Forms are now
> being used for major data entry functions that go way beyond
> their origins as a basis for more complex search requests.
>
> There is a server side issue here too. What can server cgi programs
> expect to receive? If the form input is going to a mailbox, the
> receiver of the mail may see only long lines truncated at 80 columns.
> If the form input is going to be displayed within an HTML document, it
> will be wrapped properly if it is not within <PRE></PRE> tags, but
> then it will be one big paragraph.
>
These different examples illustrate that the form input is just an input
to a server program. It is the server program that determines the SEMANTICS
of what is being sent. If one examines the wide range of applications of
forms on the web currently, the only common factor is that forms provide
data entry fields in client-server applications.
> Another related issue is how large VALUE strings and input fields can
> be. Servers have to know how large of a VALUE string they can send,
> and clients have to know how large of an input string they can send.
> Similarly, how large can URLs be?
>
The same considerations apply to values and url's. They can be arbitrarily
large dependent on the semantics of the application. This is a normal
problem in an interactive system. A user's activities are circumscribed
by what it makes sense to do within the context of the application. If
a user action is meaningless then it is a user error, otherwise the
system designer should have set up the system to function correctly.
A problem with WWW clients is that the designer may not be able to
find a client currently that does not impose some limitations. Another
problem is that the the user may have configured the client incorrectly
for the application. The first problem will disappear with the evolution
of clients. The second make desirable some capability for the server to
be able to check features of the client.
At the server end there should be no problem since the software is totally
under the control of the system designer. Again, limitations arise if
the designer attempts to use some existing servers and cgi mechanisms,
but these are far more easily overcome than client limitations.
All these issues are arising because the addition of the forms capability
enabled general client-server applications to be supported through WWW.
What was originally designed as an information retrieval system is being
used to support highly interactive applications, tele-robotics, MUDs, etc.
The standardization of HTML 2.0 has clarified the existing GUI, and Dave
Raggett's prototyping of HTML 3.0 is adding better control of interactivity
in the GUI through scripts (which could be used to provide feedback to
a user if a value entered was meaningless at some coarse level such as
too long).
Tim Berners-Lee's original specification of the HTTP protcol provides for
client-server negotiation, and this needs similar standardization to
support applications that depend on client features that are not universally
supported.
One issue that it would be nice to revisit is the way in which form data
is packed into a string and returned by POST. Historically, the current
format is a decision made by Marc Andreessen in order to get Mosaic 2.0 out.
It bypassed discussion about using MIME multipart and other formats to
return form data to the server.
The current format is adequate and easily decoded, but incongruous with
the use of the MIME standard elsewhere. It would be cleaner to move to
a MIME multipart format as the standard while retaining the current
=&% escaped format as a depreciated usage for a few years.
b.
Brian Gaines Knowledge Science Institute, University of Calgary
gaines@cpsc.ucalgary.ca Calgary, Alberta, Canada T2N 1N4
http://ksi.cpsc.ucalgary.ca/KSI/KSI.html