W3C home > Mailing lists > Public > uri@w3.org > November 2006

Re: [Uri-review] Re: The 'javascript' scheme

From: Martin Duerst <duerst@it.aoyama.ac.jp>
Date: Thu, 09 Nov 2006 19:06:05 +0900
Message-Id: <>
To: Paul Hoffman <phoffman@imc.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, Graham Klyne <GK@ninebynine.org>
Cc: uri@w3.org, uri-review@ietf.org

I tend to agree with Bjoern and Paul here that 'javascript:'
is a perfectly valid URI scheme, for the following reasons
(not all of them totally consistent maybe, but all of them
pointing in the same direction):

- It very often results in actually getting a representation.
  The way this is done is often much more complicated and
  context-dependent than e.g. for http:, but that's because
  it's turing-complete, after all.

- There are many bad and useless uses of javascript: URIs, but there
  are also extremely useful and appropriate uses. The one I'm personally
  most fond of are bookmarklets (also called favelets).

- Graham is asking how a representation (e.g. Web page) obtained
  as the result of 'dereferencing' (i.e. executing) a javascript:
  URI can be considered as the representation of that resource.
  Well, take a bookmarklet that lets you validate a Web page
  with the W3C validator. The resource is "Validate current Web page",
  the representation obtained is the validator output. As a resource,
  this is just as valid as "today's weather in Oaxaca"
  (see http://www.w3.org/TR/webarch/#intro).

- To use another analogy, assume I put up a CGI script somewhere
  on a server that (with all security bells and whistles) executes
  some snippets of programs in a particular programming language,
  and returns the results. The script is given in the query
  part of the http uri that points to my server CGI.
  How is this conceptually different from a javascript URI?
  The syntax is different, but the concepts are very similar.

- As Paul points out, not all URI schemes obtain representations,
  but they still designate resources. The mailto: URI scheme
  (currently RFC 2368, efforts for updating it underway as
  describes this as follows:
     A mailto URL designates an "internet resource", which is the mailbox
     specified in the address. When additional headers are supplied, the
     resource designated is the same address, but with an additional
     profile for accessing the resource. While there are Internet
     resources that can only be accessed via electronic mail, the mailto
     URL is not intended as a way of retrieving such objects

- We have other cases that are context-dependent, in particular
  the file: URI.

- <cynical pragmatic mode>
  If tomorrow, we found some new cool and useful way to let something
  happen when clicking on a link in a Web page, or otherwise when
  activating a field that contains an URI, we would just create
  an URI scheme for it, and would try to make the URI theory
  (resources, representations, and such) fit the practice. And if
  the theory wouldn't be able to explain things, we would/should
  get a better theory, not try to exclude useful functionality.
  </cynical pragmatic mode>

Regards,     Martin.

At 08:46 06/11/09, Paul Hoffman wrote:
>At 11:23 PM +0100 11/8/06, Bjoern Hoehrmann wrote:
>>When you click on one of the following links,
>>   <a href='news:de.comp.text.xml'>...
>>   <a href='mailto:example@example.org'>...
>>   <a href='mailto:example@example.org?body=...'>...
>>   <a href='telnet://example.org'>...
>>   <a href='irc://irc.example.org/channel'>...
>>   <a href='tel:555-5555'>...
>>would you say your browser obtains representations?
>That is, some URI schemes get representations, and many others get actions. We have dealt with this for a very long time, particularly when we worked on the big revision to mailto: in 1997-1998.
>Uri-review mailing list

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp      mailto:duerst@it.aoyama.ac.jp    
Received on Thursday, 9 November 2006 11:00:33 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:49 UTC