Date: Wed, 3 Jul 1996 00:15:13 +0200 From: firstname.lastname@example.org (Danyel Ceccaldi (M. Kokula)) Message-Id: <9607022215.AA07702@osiris.igd.fhg.de> To: email@example.com Subject: Re: Proposal: New Anchor attributes Cc: JHTaylor@videodiscovery.com 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:firstname.lastname@example.org>, everything else into the trashcan. The opinions expressed or information passed here are my own, and do not reflect those of my employer.