Re: Round 2: moving HTTP 1.0 to informational

On Wed, 10 Jan 1996, Arjun Ray wrote:
> On Wed, 10 Jan 1996, Chuck D'Antonio wrote:

> I think Snowhare is saying that, currently, 
>   1. A <FORM> is the *only* interface to the HTTP POST transaction.
>   2. An <A> is *restricted* to the HTTP GET transaction.
>   3. This orthogonality is running afoul of broken caching behavior,
>      perhaps among other infelicities in browser implementations.


> Moreover, a GET is possible through a <FORM>: thus a "symmetry"(?)
> argument/suggestion that a POST be possible via an <A>. This 
> additional semantic won't be obvious from a HREF alone (besides, 
> GET is the default semantic associated with all http url's), so
> again by similarity a `METHOD' attribute to modify the semantics.


> > > Why not re-visit 'A' containers and relieve the URL overloading
> > > by adding 'INPUT' type elements as allowed content and adding the
> > > 'METHOD' attribute to 'A' (not to be confused with 'METHODS', although
> > > dangerously close in spelling)?
> > 
> > This confuses me as well, since 'A' is already a container.  I'm not
> > sure if what you're suggesting is making it a container or changing the
> > content model substantially.  
> I think Snowhare is proposing functionality through a few extra
> attributes only, with no changes in content models.

Not exactly. 

Strictly, what I was suggesting was the addition of general method (sp. 
POST) functionality to 'A' (with consequent requirements for adding 
'INPUT' elements to the content model for 'A' and a 'METHOD' attribute to 
the 'A' element) (a little bit messy at the DTD end) or adding a new 
'TYPE="' value to the existing 'INPUT' element with the intended usage of 
being a 'SUBMIT' with the display being explictly inline text of rather 
than the 'Big Buttons' the graphical browsers all use for for 
'TYPE="SUBMIT"' now (at the cost of moderately higher complexity for the 
CGI/HTML author due to the semantics of FORMs).

> > While the 'A' content model does have
> > many failing from the perspective of hypertext development, I'm not
> > certain that the inability to use 'A' for user input is one of them.
> What about <ISINDEX>? Currently, you have to fetch the object
> before you discover that it's searchable, whereupon you'd have
> to go through a second GET (with '?whatever' tacked onto the
> original URL.) Consider the possibility of this searchability
> being available through the markup in the *linking* document:
> when the user selects the link, a user-input box is presented to
> receive the keyword. At this point, you may also need the
> flexibility of a *POST* transaction being performed. (OK, I'm
> stretching things a bit, but this is what I've read into
> Snowhare's suggestion.)


Benjamin Franz

Received on Thursday, 11 January 1996 13:20:51 UTC