Re: Enhancements to Forms - another loss??

On Tue, 11 Feb 1997 BruceLeban@akimbo.com wrote:

> >From:	sja20@hermes.cam.ac.uk (James Aylett)
> >This sounds to me a lot like the idea of specifying multiple URL's for a
> >single resource, which I seem to remember being thrown around sometime
> >last year.
> 
> So something similar to what I suggested, maybe a <SUBST> tag that 
> substitutes attribute values. Something like:
>    (1)  <SUBST other-attributes...>
>    (2)  <SUBST ERROR=problem(s) other-attributes...>
>    (3)  <SUBST CHOICE=pref(s) other-attributes...>
>    (4)  <SUBST ERROR=problem(s) CHOICE=pref(s) other-attributes...>

[Further description snipped]

Forgive me if I disagree completely with this way of doing things. The
problem I believe you're addressing is in fact three-fold. The situations
where it is useful to specify alternative resource identifiers are as
follows:

1) Alternative representations of the same resource.
2) Alternative schemes for accessing the same resource.
3) Alternative sites holding the same resource.

The first is already dealt with by HTTP/1.1 [1] using headers in the
Accept[-*] headers, and so is unnecessary in HTML.

I think we should ideally use the same reasoning to avoid, wherever
possible, putting cases 2) and 3) into HTML as well. It is much 'neater',
both in terms of usage and organisation, if we use a resource identifier
which is truly universal - ie one that identifies the resource, rather
than a particular instantiation of a resource. URLs do not meet this
requirement, since (for instance) <URL:http://foo.bar/ftp/sample> may be
the same resource as <URL:ftp://foo.bar/sample>. More importantly, the
same host and pathname but a different but related scheme (eg http and
https) have different locations in the URL hierarchy.

This is being addressed by URNs [2]; a general method described for
resolving URNs to results as part of an IETF draft [3] (either the
resource itself, or for a locator pointing to the resource) allows in
theory for negotiation over access and addressing schemes, and also over
which host to contact to obtain the resource.

In my opinion it would be incredibly foolish to start adding unnecessary
and confusing support into HTML for a problem for which a more
wide-ranging solution is already being developed. Having said that, the
current work on URNs appears, at least to me, to be restrictive in its
direction, being aimed specifically at long-lived resources and
references. That notwithstanding, the generalised approach is more
powerful and 'clean' by far than any markup-based method of specifying the
same information.

James

[1] RFC 2068, Hypertext Transfer Protocol -- HTTP/1.1
[2] See RFC 1738, Functional Requirements for Universal Resource Names
(informational)
[3] IETF draft "Requirements and a Framework for URN Resolution Systems",
draft-ietf-urn-req-frame-00.txt

-- 
/-----------------------------------------------------------------------------\
  James Aylett - Crystal Services (crystal.clare.cam.ac.uk): BBS, Ftp and Web
     Clare College, Cambridge, CB2 1TL -- sja20@cam.ac.uk -- (0976) 212023

Received on Wednesday, 12 February 1997 16:43:08 UTC