Re: The 'javascript' scheme

I have rather mixed feelings about this proposal.

On one hand, it clearly describes a common practice that is better documented
than not, and as such is to be welcomed.

On the other hand, I struggle to see how a javascript: URI-like string can be
conceived as a "resource identifier" in the sense of RFC3986:
[[
   A Uniform Resource Identifier (URI) provides a simple and extensible
   means for identifying a resource.
]]
-- http://www.ietf.org/rfc/rfc3986.txt

What is the "resource" that is identified by a javascript: URI?  If you mean the
javascript code, then how is the result of dereferencing the URI [1] (executing
the code) to be considered a "representation" of that resource?  In this
respect, I find the comparison with data: URIs to be misleading, since the
resource identified by a data: URI is clearly represented in some way by its body.

In your text, you seem to say that the javascript code *is* the resource ("The
first operation, content retrieval, defines which script code a given
'javascript' resource identifier represents").  But I don't see that the result
of executing the code (your notion of dereference: "The second operation,
in-context evaluation, is often implemented by web browser applications, and
provides a means to run custom script code when the resource identifier is
dereferenced") really corresponds to being a representation of that resource.

BTW, how does your description of what happens when a javascript: is
dereferenced ("when the user activates the hyperlink, the web browser will pass
control to the doSomething() function, and if the function returns something,
render the result in place of the current document") when the code forces a new
page to be loaded in the browser (e.g. updating the Window.location object) --
in this case, I don't see how the result can be described as a "representation"
in the sense of RFC3986 [1].

...

In summary, the difficulty I have with this specification (if I'm understanding
it correctly) is the implied claim that the result of executing a piece of
javascript code is somehow a representation of that code.

#g
--

[1] Further text from RFC3986 dealing with "dereferencing":

[[
   Given a URI, a system may attempt to perform a variety of operations
   on the resource, as might be characterized by words such as "access",
   "update", "replace", or "find attributes". [...]

   :

   When URIs are used within information retrieval systems to identify
   sources of information, the most common form of URI dereference is
   "retrieval": making use of a URI in order to retrieve a
   representation of its associated resource.  A "representation" is a
   sequence of octets, along with representation metadata describing
   those octets, that constitutes a record of the state of the resource
   at the time when the representation is generated.
]]
-- http://www.ietf.org/rfc/rfc3986.txt, section 1.2.2

(I note that using javascipt: in a browser address bar, or clicking on a
javascript: hyperlink, are operations that correspond in that application to
dereferencing the URI.)



Bjoern Hoehrmann wrote:
> Hi,
> 
>   http://www.websitedev.de/ietf/draft-hoehrmann-javascript-ri-00.txt is
> a first draft defining the 'javascript' scheme. I intend to submit it
> for publication once publication resumes and I've figured out a good way
> to remove the normative reference to RFC 4329. I would appreciate feed-
> back concerning a better Abstract, a better first paragraph in the In-
> troduction, and what to do about the RFC 4329 reference. Also note:
> 
> As I understand RFC 4395 the template does not have to be part of the
> document; it would be rather silly to include one, so I've omitted it.
> RFC 4395 has a non-normative recommendation
> 
>   Those who wish to describe resource identifiers that are useful as
>   IRIs should define the corresponding URI syntax, and note that the
>   IRI usage follows the rules and transformations defined in RFC 3987.
> 
> This recommendation does not make any sense to me, so I did not do that
> either, at least not as I understand the text. I think I met the SHOULD
> level requirements concerning use of "/", ".", and ".." to the extent
> feasible. Concerning reserved characters, I think the draft is clear
> enough about it, if anyone thinks I absolutely have to state explicitly
> that no characters are reserved, please let me know.
> 
> RFC 4395 further has
> 
>   In particular, Section 7 of RFC 3986 [5] describes general security
>   considerations for URI schemes.  The definition of an individual URI
>   scheme should note which of these apply to the specified scheme.
> 
> I did not do this as I would not know what to write, except perhaps
> that "Rare IP Address Formats" are obviously irrelevant to this scheme.
> I believe the draft meets all MUST-level requirements of RFC 4395.
> 
> The issue of handling <javascript:_scrollTo('#example')>-style
> references is discussed in the Interoperability Considerations section.
> I think it would be possible to specify equivalent processing as part
> of the specification without violating the letter of the relevant
> specifications, but I wouldn't enjoy the inevitable discussion about
> how this violates the spirit of those specifications. What I have now
> is not without its problems, if there were specifications as suggested
> in the draft, you would typically be able to tell whether it is im-
> implemented thusly (e.g. by returning a HTML document with a script
> that check window.location.href) which would then reveal that current
> implementations do not behave this way, but oh well.
> 
> Why the in-context evaluation operation is not fully defined in the
> document is explained in the Introduction. I considered to at least
> specify that the code is evaluated as global code, but once I do that
> someone would have the brilliant idea of defining that the 'this'
> object is not bound to the global object, and implementations would
> quickly be considered non-compliant. I also considered saying some-
> thing about javascript:void(...) style references, but I don't think
> this would be useful either.
> 
> (An example of implementations actually disagreeing how to implement
> in-context evaluation is javascript:'&ouml;' in an XHTML document).
> 
> I considered also defining the 'ecmascript:' scheme as it is used in
> ISO/IEC 19775, but I don't think this is quite a 'permanent' scheme
> and provisional schemes cannot be registered from standards track
> documents, as I read RFC 4395. I might ask the Web3D Consortium to
> take care of that scheme in some other way.
> 
> Finally, I thought about saying something about problems like when
> using javascript:example(...) and users try to open that in new
> windows or tabs, or mention bookmarklets, but I haven't found a good
> way to fit that into Abstract/Introduction without making them much
> longer.
> 
> Thanks,

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Wednesday, 8 November 2006 14:54:06 UTC