Re: Proposal: New Anchor attributes

Jim Taylor <JHTaylor@videodiscovery.com> wrote:
>I also think alternate anchor targets is good idea (which is why I made a
>similar suggestion to this group 2 months ago).

I agree. The point was also discussed in earlier times. It would be perfect,
if we would have URC (Uniform Resource Characteristics), but we don't, and as
far as I know we're far away from them.
Currently there are no proposals defining such mechanisms for HTML or by special
URL-encodings, or at least I don't know of any.
And because it is a very difficult matter, you have lots of choices and lots of demands
for such a thing, it would be a long process to have a working draft in a quality
that allows the suggestion to implement it.

>... For example, if I
>have a body of HTML documents on a CD-ROM, I would like to be able to
>give Internet addresses as the primary targets and CD-ROM filenames as
>the secondary targets. ...
For most special needs of such mechanisms it is enough to extend/modify an existing
proxy-application or create an own small proxy-application to solve the problem.
This has the great advantage of being browser independant, because almost
every browser allows using of a proxy.
And it is definitly not a problem which should be solved in HTML, because
HTML, as a SGML-like format, defines structured documents, and the
requested mechanism is a resource handling and/or transfer protocol problem.
But if you solved the problem, it should be integrated to the HTML-standard.

IMHO:
First there should be a discussion how to solve the general problem of
enhanced anchors resulting in a proposal.
Then there should be - a short - phase of encoding/including the mechanism
in HTML by defining new TAGS, ATTRIBUTES, or by enhancing the current encoding
of URL's.


>Complete functionality would need to include (at minimum) support for the
>following options:
Here are some additional 'options' for an 'enhanced anchor' mechanism:
-backward compatibility: default link should be interpreted correct by current browsers
-backward compatibility: enhancements should not create errors in current browsers, if possible
-link selection by:
>- timeout
>- author-specified priority (including groups of URLS)
>- modification-date priority
 -costs of the connections
 -privacy of the connection
 -quality of the connection
 -existance of a network connection
 -existance of a firewall
 -speed of the connection
 -maximum actuality of the resource delivered by resolving the link (CD-ROM scenario)
 -user preferences
 -clientside content-negotiation (see draft http 1.1 revision 5)

Possible places for defining the requested functionality:
-encoding of URL's (rfc1738, update announced for the next time)
-HTTP-Protocol, Proxy implementation of the HTTP-Protocol
-URC, URN, URI (don't know if there are still existing WG dealing with them)
-HTML


Bye
   Danny

---------------- mailing list signature of Danyel Ceccaldi
Please post constructive comments and replys to the list (and to only ONE list),
everything personal and minor comments to me <URL:mailto:ceccaldi@igd.fhg.de>,
everything else into the trashcan.
The opinions expressed or information passed here are my own,
and do not reflect those of my employer.

Received on Tuesday, 2 July 1996 18:15:31 UTC