- From: Benjamin J. Simpson <arcben@hotmail.com>
- Date: Fri, 2 Jun 2000 12:49:11 -0700
- To: "Kynn Bartlett" <kynn@idyllmtn.com>
- Cc: <w3c-wai-ig@w3.org>
From: "Kynn Bartlett" > BTW, this is why frequent readers of my (other, longer) sig will have > noticed that I use "plus links" -- such as http://kynn.com/+koosh > (warning: picture content, no text description) -- when I am giving > out link references in my signature file. >The actual URI for that page is: >http://www.ma...etc...y=128 >Which would -you- rather write on a napkin? :) This sounds like a reasonable way to write URIs, especially on napkins. I'd like to understand more about the advantages and disadvantages of doing this. Have you encountered anything interesting? I think that http://kynn.com/+koosh involves more than a good way to remember the location of a resource. What your doing is giving a URI to a URI. What kinds of characteristics does this imply? What if I put a link on my page, http://ben.com/+hairball, that points to http://kynn.com/+koosh? When alls said and done, the effect of following one of these links is that I go to http://www.dogshow.com/spring96/pictures/he0661-4.jpg You went a little further and put additional naming characteristics into your link " (warning: picture content, no text description) ", and this brings up issues with URI identity. You control the identity and significance of your URI, but you do not control the resource it points to. Your URI has a name with meaning, but the resouce (http://www.ma...etc...y=128) does not. This brings up controll of accessibility. Your sight can be less or more accessible depending on what URI's you generate, and what resources you point to. So my site's accessibility is dependant on your site. What kind of effects does this interdependance have? On an offshoot of this - when a person follows that link (http://kynn.com/+koosh) or any other like it, they are sent to an outside site - but perhaps expecting to stay within your site. Suddenly the formats and layouts all change and different browser requirements are created. This might be tough, for example, for screenreaders to handle. Thanks for you time, Benjamin J. Simpson Education Associate Web Development Group NASA Ames Research Center Mountain View, CA
Received on Friday, 2 June 2000 15:50:03 UTC