Re: Round 2: moving HTTP 1.0 to informational

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

> On Jan 9,  8:11am, Benjamin Franz wrote:
> 
> > A thought occurs to me - the artificial distinction between
> > 'A HREF' and 'FORM' is at the core of more than one problem with HTML
> > (like URLs that choke SGML validators with imbedded '&' chars because
> > the defined standard for passing parameters seperates them with '&'
> > chars).
> 
> [...] I don't this this should cause a validating parser to choke on an '&'
> in the attribute.  I am aware that sgmls will attempt entity replacement
> within 'CDATA'

Yes, in parsing attribute value specifications.

> [...] But I'm under the
> impression from [1] and [2] that 'CDATA' allows markup characters including
> '&' without any activity from the parser.  

Yes, in the *content* of the element with CDATA declared content.

> The explanation from [1] seems
> to note this as the main distinction between 'CDATA' and 'RCDATA'.

Unfortunately, a similar distinction is *not* available when parsing
markup (as opposed to content), i.e. `RCDATA' isn't available as the 
declared value in an attribute definition.

See, for instance, <URL:ftp://ftp.ifi.uio.no/pub/SGML/productions>,
esp. rules [141]-[145], and [32]-[35]. In particular, [34] specifies 
the contents of an attribute value literal between the delimiters to 
be replaceable character data. So, it's not a bug in sgmls: it's just 
an unfortunate overloading of `CDATA' with dissimilar meanings:-(

This particular confusion seems to come up again and again.

> The HTML 2.0 RFC [3] and the HTML 3.0 draft [4] both use 'CDATA' as the
> content model of 'ACTION' and 'HREF'.  In [4], in fact, they use the same
> entity to parameterize their content.  I'm perhaps a bit confused about
> why this does not address the problem you call "the artificial distinction
> between 'A HREF' and 'FORM'."
> 
> I'm interested in hearing an expansion of your ideas concerning this
> distinction.  

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.


> 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.)


Regards,

Arjun Ray

Received on Wednesday, 10 January 1996 16:57:07 UTC