Re: Standardizing new HTML features

• Mail folder: WWW Talk Apr-Jun 1993 Archives
• Next message: Dave_Raggett: "Re: Standardizing new HTML features... WE'RE INTERESTED!"
• Previous message: Tim Berners-Lee: "Re: Postscript Behavior..."

From: Dave_Raggett <dsr@hplb.hpl.hp.com>
Message-id: <9304281156.AA15496@manuel.hpl.hp.com>
Subject: Re:  Standardizing new HTML features
To: weber@eitech.com
Date: Wed, 28 Apr 93 12:56:45 BST
Cc: www-talk@nxoc01.cern.ch
Mailer: Elm [revision: 66.36.1.1]

Jay C. Weber writes:

> Three cheers to you for starting to pull together HTML enhancements!

Thanks!

> On the subject of query forms, maybe I just don't understand where
> Tim's old <QUERYFORM> ideas were heading, but we're working on an
> approach that I like better.  I hinted at it in a recent message
> regarding variable substitution, here's more detail.

> Define new tags for acquiring information from the user about an
> object retrieval.  A basic set of these tags is:

....

Your proposed tags are similar to the ones I suggested some time ago.
I ended up with two new tags: <input> for bools, free text, dates
integers and floats, and <select> for single and multi-valued list
selections which can be visualized as the browser chooses. Tim suggested
that rather than introducing a new tag, the <LI> tag should be used for
specifying list members. It would take an optional parameter to specify
selected choices. Other ideas concern the need for indicating that fields
are currently in error or can't be altered (grayed out).

> Either way, the key is that these tags set variables, named by VAR
> parameters, first to the default value and then to any input by the
> user.  These variables can then be substituted into URLs, thereby
> dynamically creating URLs based on how the user fills in a form.

We seem to have several ways of passing the field contents to the server:

    a)  as part of the URL following a "?"
    b)  as part of the URL using variable substitution
    c)  as part of the TEXTSEARCH method with HTRQ/V1.0
    d)  as part of a new 'method'

One suggestion that would fit well with existing practice is to specialise
the format of the search string. The BNF for URL's defines the search string
as zero or more alphanumeric or symbol chars, where the symbols belong
to the set: "$-_@!%^&*()."  You can then pass a list of field values using
the BNF:

    QUERY  ::=  FIELD [+QUERY]
    FIELD  ::=  name@value | name@(VALUES)
    VALUES ::=  value [&VALUE]

e.g. "name@value+name@(value&value)

The use of brackets for multiple values allows servers to continue to treat
the characters &, ^, ! for logical operators.

Any comments?

Dave